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Abattact 

Accurate  schedule  estimation  In  software  development 
programs  Is  important  because  delays  in  the  schedule  of  a 
software  development  program  can  cause  delays  in  the  entire 
schedule  of  a  %#eapon  system. 

In  order  to  more  accurately  predict  the  schedule  of  a 
software  development  program,  estimators  need  to  know  %rhich 
developawnt  factors  affect  schedule.  This  thesis  reports 
twelve  factors  identified  as  heavily  influencing  software 
development  program  schedules.  These  factors  were  determined 
through  extensive  reviews  of  literature  mitten  by  software 
development  experts  and  from  interview  with  DOD  Program 
Managers/Bngineers  and  commercial  experts  who  have  had 
experience  with  software  development  programs. 

Also,  there  are  many  commercial  softmre  development 
estimation  models  on  the  market  today.  Five  of  these  models 
were  analyzed  for  their  accuracy  in  predicting  software 
development  programs.  The  models  analyzed  %mre  COCOMO, 
PRICB-8,  S0FTC08T-R,  8PQR/20,  and  8y8TBM-3.  Inputs  to  these 
models  were  also  analyzed  for  their  correlation  to  schedule 
prediction,  )  /: - - - 
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AN  ANALYSIS  OF  SCHBOULB  DBTBRMI NATION 


IN  SOFTVARB  DBVBLOPMBNT  PROGRAMS  AND 
SOFTVARB  DBVBLOPMBNT  BSTIMATION  MODBLS 


I.  INTRODUCTION 

General  laaue 

In  today's  Defense  world,  the  use  of  the  computer  Is  no 
longer  a  new  phenomenon.  The  widespread  use  of  computers  in 
military  weapon  systems  has  made  softtmre  development  cost  an 
important  part  of  a  %feapon  system's  cost  estimate.  The 
ability  to  determine  the  cost  of  the  software  used  in  these 
computers,  ho%rever,  is  still  in  a  groirth  state.  Volume  I  of 
the  Doty  Associates,  Inc.  software  Cost  Betiiatlon  Study 
expands  this  belief. 

Since  the  advent  of  modern  computers,  it  has  been 
comawn  for  the  cost  and  tiaw  required  to  develop 
software,  particularly  for  large  programs,  to 
exceed  initial  estiMtes.  In  addition,  the 
increased  sophistication  of  software  applications 
over  the  past  ten  years  has  made  these  erroneous 
estimates  more  significant  in  terms  of  absolute 
costs  (18:11. 

Although  this  study  %fas  written  in  1977,  these  statements 

still  hold  true  today.  Barry  Boehm,  developer  of  the  COCOMO 

softirare  development  program  estimation  model,  continues  on 

the  need  for  software  cost  estimation. 

There  is  no  good  way  to  perform  a  software  cost- 
benefit  analysis,  breakeven  analysis,  or  make-or- 
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buy  analysis  without  some  reasonably  accurate 
method  of  estimating  software  costs,  and  their 
sensitivity  to  various  product,  project  and 
environmental  factors  [5:301. 

The  schedule  of  the  softi#are  development  project  Is  one 

major  contributor  to  the  project's  cost.  Schedule  risk,  an 

aspect  of  scjiedullng,  has  a  large  Impact  on  how  much 

additional  cost  may  be  Incurred.  Alan  Vingrove,  In  his 

recent  article,  "The  Problems  of  Managing  Software  Projects,” 

suggests  schedule  Is  even  more  Important  In  larger  sized 

software  development  programs  when  he  States, 

Prom  the  evidence  It  would  appear  that  any  project 
%rhlch  Involves  a  significant  software  content  runs 
a  high  risk  of  being  completed  late  and  costing 
significantly  more  than  budgeted  [46:31. 

Because  of  today's  more  advanced  and  complex  software 

that  Is  continuously  being  developed  for  national’  defense, 

schedule  and  schedule  risk  Is  an  area  that  must  be  frequently 

examined  In  order  to  develop  new  and  more  precise  methods  for 

Its  estimation.  When  schedule  is  accurately  estimated,  cost 

estimates  will  Improve  with  accuracy  and  overruns  will  be 

curtailed. 

OctinitlQna 

Before  continuing  the  Introduction,  some  key  terms  that 
will  be  used  throughout  this  research  effort  will  be  defined. 

Computer  Software  Component  (CSC).  A  CSC  Is  a  lower 
sub-dlvlslon  of  Computer  Soft%#are  Configuration  Items  (CSCIs) 
or  CSCIs  that  have  been  partitioned  Into  smaller  units 
(21:3). 
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CSCIs  are 


Computer  Software  Configuration  lte»  (C8C1). 
computer  proqrama,  or  groups  of  computer  programs  satisfying 
common  functions.  They  are  managed  as  separate  entitles 
(21:3);  each  CSCI  follo%#8  Its  own  development  cycle.  CSCIs 
will  be  discussed  later  In  a  review  of  DOO-Standard  (DOD-Std) 
2167. 

Coat  Model.  The  AFSC  Cost  gatlmatinQ  Handbook  defines 
cost  model  as  "an  estimating  tool  consisting  of  one  or  more 
cost  estimating  relationships,  estimating  methodologies,  or 
estimating  techniques  used  to  predict  the  cost  of  a  sys¬ 
tem..."  (41:8-2). 

Milestone .  John  Boddle,  author  of  Crunch  Mode: 

Building  Effective  Svatama  on  a  Tight  Schedule,  states,  "A 

milestone  event  Is  an  event  that  must  occur  If  the  project  Is 

to  be  completed.  The  combination  of  the  event  and  the  date  It 

should  occur  comprise  a  milestone  (3:58). 

Schedule .  A  "timed  plan"  for  coiapletlng  a  wor)c  package 

(12:146).  In  his  article,  "Managing  Software  Development 

Projects  for  Maximum  Productivity,"  Norman  R.  Howes  states: 

The  purpose  of  scheduling  is  not  only  to  predict 
%rhen  a  job  can  be  coa^leted  given  the  sequence  of 
work  and  the  resources  available,  but  also  to 
establish  start  and  end  dates  for  each  work  package 
(23:291. 

Schedule  Risk.  Schedule  risk  Is  the  probability  of  a 
software  development  program  not  being  completed  within  the 
time  frame  for  which  It  has  been  budgeted  (41:A-65). 
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software  D^velopaant  Prolect/Prooraa.  A  software 

developawnt  program  or  project  Is  the  process  of  engineering 

software  to  be  used  in  conjunction  with  some  type  of 

hardware.  Paul  Rook  continues  this  definition  in  the  article/ 

"Controlling  Softviare  Projects." 

The  clear  emphasis  in  the  modern  approach  to 
soft%nire  engineering  is  to  focus  attention  on  the 
overall  developswnt  process.  This  is  the  aim  of 
structured  software  development,  %diich  breaks  down 
the  project  into  a  series  of  distinct  phases,  each 
with  %fell  defined  goals,  the  achievement  of  which 
can  be  verified,  ensuring  a  sound  foundation  for 
the  succeeding  phase  [37:71. 

And  finally,  as  another  example,  Norden  defines  a 
development  project  as  "a  finite  sequence  of  purposeful, 
temporally  ordered  activities,  operating  on  a  homogeneous  set 
of  problem  elements,  to  meet  a  specified  set  of  objectives  . 

.  ."  (27:74). 

Virtual  Machine.  Boehm  states  that  "for  a  given 
software  product,  virtual  machine  is  the  complex  of  hardware, 
and  software  it  [the  computer]  calls  upon  to  accomplish  its 
task  (6:510). 

specific  Problem 

Because  delays  in  schedule  can  have  a  substantial 
adverse  affect  on  costs,  program  managers  need  to  know  how 
and  to  %rhat  extent  schedule  risk  should  be  included  in 
software  development  cost  estimates. 
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The  Cost  Analysis  Branch  of  the  Aeronautical  Systems 
Division  (ASD/ACC)  of  Air  Force  Systems  Command  at  Wright- 
Patterson  Air  Force  Base  has  requested  that  AFIT  thesis 
research  be  done  in  the  area  of  software  development  cost 
estimating  (43).  Schedule  risk  plays  an  important  part  in 
accurately  estimating  the  cost  of  a  software  development 
program.  Determining  how  and  to  %rhat  extent  schedule  risk 
should  be  included  in  soft%#are  development  cost  estimates 
will  increase  the  accuracy  of  the  estimates  and  allow  %feapon 
system  program  managers  to  better  budget  their  resources. 

Assumptions 

The  following  assumptions  are  made  for  this  research: 

•  • 

1)  The  manner  in  which  schedule  risk  is  incorporated 
into  current  software  development  cost  models  can  be  inferred 
from  current  literature  and  software  development  cost  model 
documentation. 

2)  Historical  data  on  estimated  versus  actual  costs  of 
software  development  programs  can  be  obtained  from  Electronic 
Systems  Division  (BSD),  Cost  Analysis  Branch  (ACCR). 

3)  Cases  of  software  development  programs  at  BSD  where 
delays  in  schedule  were  reported  are  available  for  review. 
Cases  of  software  development  programs  which  were  on  or  ahead 
of  schedule  will  also  be  available  for  review. 

4)  Software  development  cost  analysts,  determined  to  be 
experts  in  the  field,  interviewed  throughout  the  Air  Force 


and  In  private  Industry,  have  sufficient  knowledge  to  ans%#er 
questions  regarding  the  deteraiination  of  schedule  risk  in 
software  developaent  cost  estinates. 

Rflagarch  -Objactlyoa 

In  order  to  thoroughly  investigate  and  derive  a 
significant  conclusion  to  the  research  problea,  the  following 
research  objectives  were  achieved: 

1)  Gained  sufficient  knowledge  in  the  subject  of 
software  development  prograM  to  understand  the  estlaatlon 
process.  Particularly,  gain  knowledge  in  the  area  of  schedule 
and  schedule  risk  in  software  development  programs  to  be  able 
to  determine  improved  methods  for  determining  it; 

2)  Developed  adequate  expertise  in  using  the.  designated 
cost  models  to  be  analyzed  so  that  the  extent  to  %rhich  the 
models  incorporate  schedule  risk  can  be  assessed; 

3)  Determined  the  relative  importance  of  schedule  risk 
with  respect  to  other  cost  drivers  in  software  development 
cost  oMMlels; 

4)  Determined  to  what  extent  schedule  risk  has  been 
previously,  and  currently  should  be  incorporated  into  cost 
models  based  on  its  determined  ii^^rtance. 

5)  Developed  criteria,  based  on  this  research,  that 
program  managers  can  use  when  determining  how  schedule  risk 
can  more  accurately  be  incorporated  into  a  cost  model. 
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The  following  Investigative  questions  are  raised  to 
support  the  research  objectives: 

1)  Vhat  are  the  factors  affecting  a  software 
developnent  program  schedule? 

2)  What  Is  the  Inportance  of  schedule  risk  to  a 
software  developawnt  program? 

a)  To  %rtiat  degree  do  program  managers  consider 
schedule  and  schedule  risk? 

3)  What  methods  for  determining  schedule  risk  are 
currently  used  In  software  development  cost  models 
and  have  they  been  tested  and/or  validated? 

a)  Which  of  these  Mthods  appear  to  be 
most  valid? 

4)  In  cost  models,  vdiat  Is  the  significance 
of  schedule  risk? 

a)  Is  schedule  risk  an  Independent  variable  or 
does  Its  significance  depend  on  the  value 
of  other  Independent  variables  In  the  cost 
models  such  as  size  of  the  program,  number 
of  programmers  required,  or  level  of 
software  sophistication  required? 

5)  Can  any  of  these  methods  be  combined  or 
incorporated  into  a  new  and  more  accurate  method 
for  accounting  for  schedule  risk  In  cost  models? 


Scope  and  Limitations 

The  following  limitations  will  define  the  scope  of  this 
research  effort: 

1)  Only  four  or  five  current  software  development  cost 
models  vrere  chosen  for  analysis. 

2)  The  selection  of  the  cost  models  depended  on  the 
availability  of  thorough  documentation  for  each  model,  the 
availability  of  the  model  Itself  and  the  ability  to  access 
these  models  to  run  case  study  data. 
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3)  Only  one  project  frooi  the  data  base  was  run  for 
analysis  ^n  each  of  the  Models. 

4)  Intervietfs  with  prograa  Managers  %rho  have  been 
Involved  In  software  developMent  prograMS  %rere  arranged 
through  points  of  contact  at  various  product  divisions 
throughout  Air  Force  SysteMS  Conaaind  and  other  USAP  Major 
cownands . 


The  process  of  software  development  is  a  very  popular 
topic  among  a  broad  base  of  people  ranging  from  specialists 
in  computer  programming,  who  are  Interested  in  all  the 
intricacies  of  programing  new  soft%raire,  to  general  program 
managers  %rtio  are  only  interested  in  the  end  result. 
Consequently,  there  has  been  a  great  deal  of  literature 
written  on  software  development  ranging  from  very  technical 
to  very  general.  Hotmver,  only  a  small  portion  of  this 
literature  specifically  addresses  schedule  and  schedule  risk 
as  a  component  in  software  development  cost  estimating. 

The  purpose  of  this  chapter  will  be  to  address  current 
vie%rs  on  software  development  cost  estimating  and,  specifi¬ 
cally,  %d)at  are  considered  to  be  some  of  the  determinants  of 
schedule.  A  review  of  the  current  Department  of  Defense 
Standard  directing  the  development  of  software  will  be  given, 
and  cost  models  that  will  be  used  in  this  research  effort 
will  be  discussed. 

Software  Development 

The  Increase  in  size  of  many  current  software 
development  projects  and  the  common  occurrence  of  overrunning 
schedule  with  its  associated  Increased  costs  has  caused  many 
major  corporations  and  the  DOD  to  examine  ways  of  improving 
their  software  development  techniques.  A  representative  from 
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TRW,  Inc.  gives  three  reasons  why  examining  software 
development  more  closely  Is  li^ortant. 

1)  Our  customers  have  sho%m  a  growing 
unwillingness  to  accept  cost  and  schedule  overruns 
unless  the  penalties  i#ere  Increasingly  borne  by  the 
software  developer. 

2)  Partly  as  a  consequence  of  1),  we  have  entered 
Into  soft%Mire  development  contracts  %rhere  both 
adherence  to  predicted  costs  and  on-tlme  delivery 
%iere  Incentlved.  That  means  we  made  more  money  if 
Me  could  predict  accurately  the  cost  and  the  time 
It  would  take  to  do  the  job. 

3)  We  found  that  Me  could  la^rove  our  estimates 
only  by  Improving  our  understanding  of  exactly  «fhat 
steps  and  processes  %«ere  Involved  In  softmre 
development,  and  this  understanding  enabled  us  to 
manage  the  effort  better.  The  better  management. 

In  turn.  Improved  our  estimates  147:1561. 

For  these  reasons.  It  Is  also  Important  that  personnel  In  the 

DOD  examine  the  processes  that  comprise  soft%fare  development 

and  understand  %rtiat  occurs  at  each  phase. 

As  noted  above,  software  development  Is  a  multi-faceted 

development  process.  It  Is  best  managed  and  understood  %rtien 

broken  do%m  Into  distinct  phases.  Norman  R.  Howes,  author  of 

"Managing  Software  Development  Projects  for  Maximum 

Productivity,"  gives  an  Interesting  perspective  on  the 

soft%fare  development  process.  He  theorises  that  soft%iare 

development  management  has  t%ro  distinct  parts:  project 

planning  and  project  execution  (23:27).  He  also  says  that 

these  two  parts  each  contain  several  distinct  sub-parts. 

With  respect  to  schedule  the  main  part  that  should  be 

analyzed,  according  to  Howes,  Is  "project  planning."  ho%m»s 

lists  five  sub-parts  to  project  planning:  subdivision  of 
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work,  quantification,  sequencing  of  work,  budgeting,  and 
finally  scheduling  (23:27). 

Normally,  software  development  is  divided  into  subsec¬ 
tions  for  different  phases  of  the  development.  An  example  of 
division  is  the  Brown  a  Root  Integrated  Control  System,  which 
Howes  helped  in  creating,  a  development  management  system 
that  divides  soft%#are  development  into  a  "series  of 
decompositions  based  on  how  the  work  will  be  performed" 
(23:27).  The  resultant  hierarchy  is  called  a  "work  breakdown 
structure"  (WB8)  (23:27).  The  concept  is  often  used  by  other 
software  development  teams  to  better  control  all  aspects  of 
the  project. 

Jack  Cooper  explains  basically  the  same  idea  for 
software  development  schedules.  He  states  that  an  effective 
way  to  develop  a  schedule  is  to  "approach  the  task  the  same 
way  you  would  approach  the  top-down  design  of  a  software 
system"  (14:24).  He  says  that  when  developing  the  schedule, 
start  at  the  top  of  the  project  and  "decompose  it  into  its 
first  line  major  tasks"  (14:24).  Next,  the  task  can  be 
further  decomposed  into  more  comprehensive  sub- tasks  until 
"the  level  is  reached  where  tasks  cannot  be  sub-divided  any 
further"  (14:24). 

Determinants  of  Schedule  Risk 

Another  area  of  interest  to  this  research  effort  is  the 
determinants  of  schedule  risk  as  perceived  by  experts.  These 
determinants  are  Important  to  any  software  development 
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project  and  can  vary  widely  depending  on  expert  opinion  and 
the  particular  case  to  which  the  schedule  risk  applies. 

Cooper  in  the  article  "Software  Development  Management 
Planning"  reiterates  this  point,  "Another  critical  action  to 
be  taken  before  proceeding  ...  is  to  identify  all  of  the 
potential  risk  areas"  (14:23).  He  goes  on  to  state,  "Many  of 
the  high  risk  areas  should  be  included  on  the  project's 
critical  path"  (14:23).  Vhlle  all  determinants  are 
important,  this  review  will  focus  on  specification, 
experience,  planning,  and  complexity. 

One  of  the  major  determinants  of  schedule  risk  has  to  do 
with  specification.  If  the  requirements  for  the  software  are 
not  properly  specified  and  defined,  accurate  schedule 
determination  will  be  difficult.  Walt  Scacchi,  in  his 
article  "Managing  Software  Engineering  Projects:  A  Social 
Analysis,"  talks  about  specification;  he  states,  "Problems 
found  in  specifications  may  be  due  to  oversights  in  their 
preparation  or  conflicts  between  participants  over  how  they 
believe  the  system  should  function"  (38:54). 

Another  factor  that  can  determine  schedule  risk  is 
experience,  specifically,  experience  that  the  software 
developers  have  with  the  type  of  software  being  developed. 

The  Doty  Associates,  Inc.  report  highlights  this  area  when 
analyzing  sizing  of  the  program  and  experience  of  the 
developer  at  the  same  time.  If  the  developer  determines  size 
estimates  in  man  months  and  secondary  resources  based  on 
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experience,  then  the  chance  for  error  will  depend  on  the 
similarity  of  his/her  previous  experience  to  the  new 
development  (18:72).  The  sizing  of  the  software  development 
program  will  in  turn  determine  its  schedule. 

The  level  of  planning  involved  is  also  a  determinant  of 
schedule  risk.  Generally,  the  more  planning  that  goes  into  a 
software  development  project  before  it  starts,  the  greater 
the  chances  it  will  run  on  schedule.  According  to  R.S.  Hurst 
in  the  article  "SPMMS-Inf ormation  Structures  In  Software 
Management, " 

Planning  includes  planning  the  project,  planning 
the  product  and  planning  the  use  of  resources;  it 
includes  choosing  the  processes  to  be  applied 
within  the  project  and  determining  the  nature  of 
the  support  the  project  will  need.  A  plan  has  to 
describe  the  relationships  between  the  tasks,  the 
intermediate  outputs  and  the  responsibilities  of 
personnel  (24:501. 

One  last  major  determinant  of  schedule  risk  discussed 
here  is  complexity.  The  more  complex  or  sophisticated  the 
software  that  is  being  developed,  the  higher  the  probability 
there  will  be  delays  or  deviations  in  schedule.  In  one  study 
of  product-related  factors  on  productivity,  it  was  found  that 
a  large  percentage  of  complex  code  was  associated  with  low 
productivity  (44:146).  Low  productivity  is  often  associated 
with  schedule  delay. 

POD  Standard  2167 

POD  Standard  (POP-STP)  2167,  "Pefense  System  Software 
Pevelopment, "  is  the  Pepartment  of  Pefense  (POP)  standard 
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which  establishes  "requirements  to  be  applied  during  the 
acquisition,  development,  and  support  of  so£t%raire  systems 
(16:1/2).  DOD-STD  2167  Is  the  result  of  a  development 
process  started  In  1979  to  standardize  acquisition, 
development,  and  support  standards  and  policies  (11:1). 

Prior  to  DOD-STD  2167,  DOD-STD's  4S3,  490,  1521A,  and  1679 
provided  the  guidelines  for  software  development  (11:1). 
Cheadle  believes  the  new  standard  loqpacts  softviare  parametric 
modeling  "because  It  requires  specific  documentation  to  be 
revle%#ed  at  specified  design  revle%«  (11:1). 

One  Important  aspect  of  DOD-STD  2167  Is  that  It  breaks 
the  software  development  process  Into  the  following  major 
activities,  which  It  says  may  overlap  or  be  applied 
Iteratively: 

1)  System  Requirements  Analysis/Design 

2)  Software  Requirements  Analysis 

3)  Preliminary  Design 

4)  Detailed  Design 

5)  Coding  and  Computer  Software  Unit  Testing 

6)  CSC  Integration  and  Testing 

7)  CSCI  Testing 

8)  System  Integration  and  Testing  (16:9). 

DOD-STD  2167  also  calls  for  formal  reviews  and  audits  to 
be  conducted  at  specified  points  during  these  software 
development  activities.  Between  System  Requirements  Analysis 
and  System  Design  Is  the  System  Requirements  Review  (SRR); 
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between  System  Design  and  Software  Requirements  Analysis  Is 
the  System  Design  Review  (SDR);  between  Software 
Requirements  Analysis  and  Preliminary  Design  Is  the  Software 
Specification  Review  (SSR);  between  Preliminary  Design  and 
Detailed  Design  Is  the  Preliminary  Design  Review  (PDR); 
between  Detailed  Design  and  Coding  and  CSU  testing  Is  the 
Critical  Design  Review  (CDR);  between  CSC  Integration  and 
Testing  and  CSCI  Testing  Is  the  Test  Readiness  Review  (TRR) 
(16:10).  After  CSCI  Testing,  three  more  reviews  occur  before 
Testing  and  Evaluation  and  finally  Production  and  Deployment. 
These  reviews  are  Functional  Configuration  Audit  (FC^), 
Physical  Configuration  Audit  (PCA),  and  Formal  Qualification 
Review  (FOR)  (16:30). 

Cheadle  believes  the  additional  regimentation  of  the 
review  process  and  the  Introduction  of  the  new  Software 
Specification  Design  Review  (the  SSR)  was  Initiated  "because 
contractors  and  contracting  agencies  were  still  discussing 
requirements  at  the  Critical  Design  Review"  (11:1).  Cheadle 
states,  "If  the  contractor,  user  and  customer  are  still 
Identifying  requirements  at  the  CDR  then  the  project  Is  In 
danger  of  overrunning  and  missing  the  schedule"  (11:1). 

Bruce  and  Pederson  state  during  the  Preliminary  Design 
Phase,  "requirements  analysis  tasks  are  performed  to 
establish  a  requirements  baseline"  (8:8).  They  go  on  to 
state  "the  requirements  are  then  analyzed  and  allocated  to 
functional  software  areas  which  results  In  a  preliminary 
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design  (8:6).  This  preliminary  design  will  provide  the 
baseline  for  the  Detailed  Design  phase  (8:8). 

Next,  further  analysis  and  design  work  on  the 
preliminary  design  baseline  results  In  the  detailed  design, 
which  forms  the  baseline  for  Coding  and  CSCI  Testing  (8:8). 
During  this  phase  the  actual  coding  and  testing  activities 
occur  (8:8). 

This  new  structure  seems  to  be  an  attempt  by  the  DOD  to 
standardize  the  phases  of  the  software  development  process. 
However,  often,  many  experts  In  soft%»re  development  have 
different  definitions  for  activities  of  a  software 
development  project  from  those  of  DOD-Std  2167.  Bruce  and 
Pederson  state  that  software  development  proceeds  through 
three  distinct  phases:  Preliminary  Design,  Detailed  Design 
and  Implementation  and  Operation  (8:8).  They  also  note  that 
It  Is  often  very  difficult  to  determine  the  actual  status  of 
any  of  these  development  activities  (8:8).  Bruce  and 
Pederson  state,  "Often  five  or  six  development  steps  are 
completed  and  three  fourths  of  the  calendar  time  and  budget 
is  expended  before  any  proof  of  progress  or  quality  Is  shown 
..."  (8:8) . 

Software  Development  Bstimatlon  Models 

This  research  will  be  conducted  with  the  aid  of 
commercially  and  DOD-developed  software  development  cost 
models.  There  are  many  of  these  types  of  cost  models 
available  for  use  today.  The  cost  models  to  be  used  in  this 
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analysis  will  be  determined  by  the  extent  to  which  thorough 
documentation  Is  available  on  the  model.  The  following 
paragraphs  describe  cost  models  that  are  candidates  for  use 
In  this  research  effort. 

The  Constructive  Cost  Model  fCOCOMO).  COCOMO  Is  one  of 
the  more  popular  soft%iare  cost  estimating  models  on  the 
market  today.  This  Is  probably  true  because  its  developer, 
Barry  w.  Boehm,  provides  extensive  documentation  as  to  how  It 
was  developed  and  how  It  works.  Users  can  make  adjustments 
to  the  model  to  fit  their  o%m  scenarios. 

Boehm  emphasizes  the  primary  reason  he  developed  the 
COCOMO  model  was  to  help  atanagers  understand  "the  cost 
consequences  of  the  decisions  they  will  make  In 
commissioning,  developing,  and  supporting  a  software  product" 
(4:13).  Boehm  describes  the  different  COCOMO  models. 

COCOMO  Is  actually  a  hierarchy  of  three 
Increasingly  detailed  aaodels  which  range  from  a 
single  macro-estimation  scaling  model  as  a  function 
of  product  size  to  a  micro-estimation  model  with  a 
three  level  work  breakdotm  structure  and  a  set  of 
phase-sensitive  multipliers  for  each  cost  driver 
attribute  (4:13). 

In  this  research  effort,  the  Intermediate  COCOMO  model 
(the  second  of  the  three  models  described  above)  was 
analyzed  for  Its  techniques  In  Incorporating  schedule.  The 
Intermediate  COCOMO  model  Is  an  extension  of  the  Basic  COCOMO 
model  (described  above  as  a  single  macro-estimation  scaling 
model).  The  Basic  COCOMO  model  Is  good  for  quick,  early 
rough  order  of  magnitude  estimates  of  software  costs,  but  Its 
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accuracy  Is  limited  because  of  the  lack  of  additional  factors 
used  to  compute  the  estlotates  (4:58).  The  Intermediate 
COCOMO  model  has  potential  for  greater  accuracy  and  a  higher 
level  of  detail,  making  It  more  suitable  for  cost  estimation 
In  the  more  detailed  aspects  of  software  product  development 
(4:58) . 

Boehm  stated,  "There  are  many  candidate  factors  to 
consider  In  developing  a  better  model  for  estimating  the  cost 
of  a  software  project"  (5:115).  To  narrow  this  large  number 
do%m  to  a  manageable  size  Boehm  subjected  each  factor  to  two 
tests: 

1)  General  Significance — The  test  for  general 
significance  eliminates  those  factors  significant  only  on  a 
small  number  of  specialized  occasions  (5:115). 

2)  Independence — The  test  for  Independence  eliminates 
factors  strongly  correlated  with  product  size  and  compresses 
factors  usually  highly  correlated  on  size  projects  Into  a 
single  factor  (5:115). 

The  'result  of  this  narrowing  of  the  number  of  factors  Is 
the  Intermediate  COCOMO  currently  uses  16  different  cost 
drivers  which  are  divided  Into  four  categories  to  estimate 
cost  (21:9).  These  categories  are  Product  Attribute, 

Computer  Attributes,  Personnel  Attributes  and  Project 
Attributes  (5:116).  The  factors  for  each  category  are 
listed  In  Table  1. 
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Table  1 


COCOMO  Factors  By  Category  (5:115-116) 

Product  Attrlbates 

Bo£ti#are  Reliability  (RBLY) 

Data  Base  Size  (DATA) 

Product  CoMplexlty  (CPLX) 

RequlresMnts  Volatility  (RVOL) 

Coaputer  Attrl,butag 

Execution  TIbm  Constraint  (TXMB) 

Main  Storage  Constraint  (STOR) 

Virtual  Machine  Volatility  (VIRT) 

CoMputer  Turnaround  Tiae  (TURN) 

Personnel  Attributes 

Analyst  C^apablllty  (ACAP) 

Applications  experience  (ABXP) 

Prograaner  Capability  (PCAP) 

Virtual  Machine  Experience  (VEXP) 

Prograaalng  Language  Experience  (LEXP) 

Project  Attributes 

Modern  Prograaalng  Practices  (MODP) 

Use  of  Software  Tools  (TOOL) 

Required  Developaent  Schedule  (SCHED) 

Note:  Requlreaents  Volatility  was  added  In  1986  (21:9). 


The  interaedlate  COCOMO  software  developaent  effort 
first  begins  by  generating  noalnal  effort  froa  scaling 
equations  (5:117).  The  equations  for  the  various  types  of 
software  are  as  follows: 


Organic 

-  3.2 

(KDSI)‘-®* 

(1) 

Seal -detached 

MMrf... 

«  3.0 

(KDSI)‘*‘* 

(2) 

Eabedded 

MMn»wi 

-  2.8 

(KDSI)*-*® 

(3) 

where, 

MM  Is  aan-SK>nths, 

KD8I  Is  thousands  of  deliverable  source  Instructions. 


19 


These  noalnal  estlaates  are  then  adjusted  using  ratings  with 

respect  to  the  other  16  cost  driver  attributes  described 

above  (5:117).  The  COCOMO  aodel  also  uses  the  Rayleigh 

distribution  to  give  approxlMtlons  to  the  labor 

distributions  for  the  soft%«are  developnent  effort  (5:68). 

The  output  of  the  IntersMdiate  COCOMO  aodel  is  the  level 

of  effort  in  person-Months  (5:115).  A  COCOMO  person-nonth 

consists  of  152  hours  of  trorklng  tiae  "which  was  found  to  be 

consistent  with  practical  experience  with  the  average  Monthly 

tiae  off  due  to  holidays,  vacations  and  sick  leave"  (5:59). 

COCCMfO  estimtes  in  person-aonths  instead  of  dollars  because 

of  "the  large  variations  bet%men  organizations  in  what  is 

included  in  labor  costs  .  .  ."  (5:59). 

PRic«-g.  PRICI-S'^'^  is  a  coaaercially  available  (Gl, 

Inc.)  aacro-cost  estiamtion  aodel  developed  priaarlly  for 

eabedded  systea  applications.  The  aodel  consists  of 

paraaetric  Methods  to  estiaate  costs  and  mnpower  for 

software  developawnt  (41:8-21).  The  APac  Cost 

Handbook  further  describes  PRICB-S. 

PRXCB-S  estlaates  probable  cost  on  the  basis  of 
project  scope,  prograa  coa^ositlon,  processor 
loading,  and  previous  organizational  perforauince. 
Operational  and  testing  regulreaents  are 
incorporated,  as  well  as  technology,  gro%fth  and 
inflation,  to  generate  estiaates  of  cost  .  .  . 

(41:8-211. 

In  addition  to  cost,  PRICB-S  will  derive  schedules  of 
work.  To  do  this,  the  aodel  exaaines  schedule  constraints 
that  have  been  iaposed  within  the  aodel  (34:1-2).  Costs  are 
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also  adjusted  to  account  for  acceleration,  stretch-out,  and 
phase  transition  inefficiencies  (34:1-2). 

The  basis  for  PRICS-S  is  a  conparlson  of  new 
requireieents  to  analogous  estlaates  in  the  past  (34:1-2). 

The  Model  relies  heavily  on  the  experience  and  judgement  of 
managers  using  the  model.  PRId-S  incorporates  this 
experience  into  variables  which  "describe  the  significant 
technological  and  cost  differences  between  individual 
projects  and  organizations  (34:1-2). 

PRICB-8  outputs  values  for  six  cost  categories  in  each 
of  the  nine  development  phases  as  prescribed  by  DOD-8TD  2167. 
Table  2  displays  the  cost  elements  and  the  corresponding 
development  phases  as  described  in  the  PRICB-8  manual  (34:1- 
1): 


Table  2 

PRICB-8  Cost  Blements  and  Associated  Development  Phases 

Development  Phases 


Coat  Blflicnt 
Design 
Programming 
Data 

8ystem  Bngineering/ 
Program  Hanagement 

Quality  Assurance 

Configuration  Management 


8ystem  Concept 

8ystem/8oftware  Requirements 

8oftware  Requirements 

Preliminary  Design 
Detail  Design 

C8C  Code/Unit  Test 

C8C1  Test 

System  Test  and  Bvaluation 
Operational  Test  &  Bvaluation 
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The  PRICB-8  Model  calculates  cost  in  teras  of  effort 
(either  person  months  or  person  hours)  and  a  typical  schedule 
for  the  development  program  (34:1-1).  PRICI-S  will  also 
perform  sensitivity  analyses  and  susmarize  effects  of 
uncertainties  (34:1-3). 

PRICES  inputs  are  grouped  into  nine  categories  as 
follow: 

1)  Project  Hagnltude — the  number  of  source  lines  of 
code  (SLOC)  to  be  produced. 

2)  Project  Application — called  Application,  tells  %dkat 
type  of  project. 

3)  Level  of  Mew  Design  and  Code — amounts  are  specified 
by  the  user. 

4)  Productivity— entails  organizational  capabilities, 
experience  and  individual  talents  of  the  activity  that  will 
accomplish  the  work. 

5)  Utilization — effort  required  to  fit  a  software 
program  into  a  processor. 

6)  Customer  Specifications  and  Reliability 
Requirements— called  Platform,  sumanrizes  operational 
requirements.  Also  used  to  describe  the  transportability 
requirements  of  a  software  project  or  how  often  a  program 
will  be  moved  from  one  type  of  hardware  to  another. 

7)  Development  Environment— called  Complexity, 
describes  the  effects  of  environmental  factors  that  can 
directly  affect  schedule  time. 
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8)  Technology  Growth — based  on  the  possibility  of  using 
new.  Innovative  developsMnt  techniques  that  Mke  the 
development  process  more  efficient.  The  key  drivers  here  are 
Productivity  Factor,  Application  and  Time. 

9)  System  Integration — factor  based  on  the  necessity  to 
merge  two  or  more  related  software  products  into  one  system. 
PRICB-S  will  develop  time  and  schedule  estimates  for  this 
activity  the  same  as  it  does  for  individual  sub-systems 
(34:1-11) . 

Regarding  schedule,  PRICB-S  basically  takes  the 
judgement  of  experienced  managers,  engineers  and  estimators 
to  determine  the  impacts  of  the  key  cost  drivers  and 
incorporates  this  knowledge  into  the  model  (34:1-12).  As 
with  any  values  based  on  expert  judgement,  these  values* 
would  be  subjective.  However,  the  PRlCB-S  Hanual  states  that 
as  much  as  possible,  "actual  recorded  data  is  used  to 
formulate,  test,  and  verify  those  assessment  processes" 
(34:1-12).  The  PRICB-8  Hanual  also  acknowledges  that  data 
does  not  always  exist.  The  manual  gives  the  example  that  "the 
impact  of  schedule  variations  on  cost  cannot  be  statistically 
processed"  (34:1-12).  Since  there  %>as  only  one  schedule  for 
programs  in  the  past,  it  is  not  certain  what  would  of 
happened  had  that  schedule  been  shorten  or  lengthened. 

PRICB-S  contends,  however,  that  by  knowing  actual  schedules 
differ  from  the  original  planned  schedule,  cost  impacts  can 
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be  Modeled  through  studying  the  processes  eMployed  to  Manage 
the  schedule  (34:1-12). 

PRICB-S  uses  the  planned  coa^letlon  date  for  Software 

Specification  Review  (SSR)  and  the  CoMplexity  factor  to 

generate  an  "internal  reference  schedule"  which  is  used  to 

calculate  effort  penalties  (34:1-8). 

When  additional  dates  are  entered  (other  than  SSR), 
new  schedule  dates  are  calculated  to  Meet  schedule 
constraints  and  they  are  coMpared  with  the 
internally  calculated  reference  schedule.  This 
coMparison  is  used  to  calculate  effort  penalties 
associated  with  phase  acceleration,  stretch-out, 
and  deviations  froM  reference  schedule  (34:1-881. 

PR1C8-S  outputs  cost  in  person-Months  or  hours  by  the 

soft%«are  the  life  cycle  phases  listed  in  DOD-STD  2167.  It 

will  also  list  schedule  InforMation  by  review  Milestone  (e.g 

SRR,  SDR,  etc.)  (34:1-3). 

SLIM.  The  PutnaM  Software  LiJscycle  Uodel  (SLIM^"*) 
Model  is  a  software  cost  estiMating  systeM  available  froM 
Quantitative  Software,  Inc.  (31:1-1).  The  Model  is  based  on 
Much  of  the  theory  developed  by  Mr.  La%rrence  PutnaM  (31:1- 
1).  SLIM  is  a  fully  interactive  Model  and  is  used  to 
generate  projections  of  cost,  tiMs,  personnel  and  Machine 
resources  for  developing  coMputer  software  systeMs.  It  is 
designed  to  handle  a  front-end  estiMating  problsM  because  it 
requires  certain  estlMate  inforMation  froM  the  start  (31:2- 
3). 

Inputs  for  SLIM  consist  prlMarily  of  three  SLOG 


estiwutes:  MlnimoM,  most  likely,  and  Mxiaua  (21:14).  The 
followinq  other  inputs  are  also  required: 

1 )  Language 

2)  Systen  Type 

3)  Description 

4)  Percentage  of  hardware  aeBM>ry  used 

5)  Experience 

6)  Modern  Practices  (percentage  use  of  new  development 
techniques) 

7)  Technology  Factor  (measure  of  difficulty) 

8)  Other  Factors  (including  labor  rates  and  economic 
factors)  (21:14). 

The  AFSC  Cost  gstlmatlno  Handbook  describes  SLIM 
outputs . 

The  model  provides  the  following  outputs: 

Identification  of  minimum  cost,  minimum  tisw, 
and  all  feasible  solutions  for  a  particular 
software  development  project 

Estimates  of  monthly  man-loading 

Optimum  schedule  for  completion  with  associated 
milestones 

Risk  profiles  for  schedule  and  effort 

Identification  of  constraints  on  manpo%rer  ap¬ 
plication  and  completion  schedules  (41:8-241. 

As  noted  above,  SLIM  gives  the  minimum  feasible  time. 

The  user  may  then  use  this  time  schedule  or  he  may 
specify  a  longer  time  in  which  he  can  take 
advantage  of  the  trade-off  law.  This  law  is  in 
essence  a  quantification  of  the  Brooks'  traote-off 
law  which  states  that  one  can  greatly  reduce  the 
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cost  and  effort  by  taking  a  little  sore  tlM 

(31:1-11 . 

SLIM  has  a  "deslgn-to-cost"  function  which  will 
generate  feasible  time  schedules  given  user -spec if led 
constraints.  SLIM  will  check  user-specified  cost  and  time 
inputs  for  feasibility  and  consistency  with  past  data  (31:1- 
1). 

SLIM  also  has  an  optional  life  cycle  output  that  will 
derive  person-months,  schedule,  and  person  loading  profiles 
(21:15).  William  G.  Cheadle  stated  that  SLIM  gives  the 
shortest  schedule  first  and  then  "it  implies  you  can  save 
money  by  moving  the  time  out  to  the  optimum  schedule”  (10). 

SLIM  relies  heavily  on  the  Rayleigh-Norden  Curve  to 
allocate  resources  during  a  project.  The  manufacturers  of 
the  SLIM  model  contend  that  the  approach  used  for  a  software 
estimating  problem  depends  on  %d)ere  one  is  in  the  software 
life  cycle  (31:2-3).  They  further  contend  that  the  software 
development  program  problem  is  a  "pure  estimating  problem” 
during  the  feasibility  and  function  design  phases  (31:2-3). 
It  is  pure  estimating  because  the  problem  uses  phenomenology 
and  past  experience  (data)  to  forecast  a  future  event  (31:2- 
3).  The  developers  of  SLIM  found  that  in  this  scenario  a 
model  of  observed  behavior  %rould  be  appropriate.  They  also 
wanted  a  model  that  allo%red  the  time  to  vary  and  had  input 
parameters  of  development  time,  development  effort  and  cost 
(31:2-3).  For  these  reasons  they  chose  the  Rayleigh-Norden 
curve  as  the  basis  for  their  model  (31:2-3). 
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SoftCoat-R.  So£tCost-R'^'^  is  based  on  the  model  Dr. 
Robert  Tausworthe  of  the  Jet  Propulsion  Laboratory  developed 
for  NASA  in  1981  (42:1-2).  This  model  is  also  based  on  the 
Rayleigh-Morden  curve  as  well  as  Putnam  theory  developed  in 
SLIM  (42:1-2). 

SoftCost-R  bases  its  estimates  from  inputs  from  the 
factors  size,  management,  staffing,  complexity  and 
environment  %rhlch  is  input  at  the  beginning  of  the  model 
operation  (42:1-2).  From  this  information,  SoftCost-R 
computes  a  resource  estimate  in  three  steps: 

1)  Size  in  Kilo  Source  Lines  of  Executable  Code  (KSLEC) 
is  computed. 

2)  Productivity  as  a  function  of  technological  and 
environmental  factors  is  computed. 

3)  Effort  is  computed  by  dividing  total  size  by 
productivity  (42:1-2). 

A  standard  WBS  is  also  used  to  produce  the  task  plan  and 
schedule  to  be  used  during  initial  project  planning  stages 
(42:1-2).  SoftCost-R  also  incorporates  a  version  of  COCOMO 
(COCOMO-R)  in  conjunction  with  SoftCost-R  into  the  estimate 
as  a  sanity  and  reasonableness  check  (42:1-3). 

Outputs  of  SoftCost-R  include  an  optimal  time  solution 
in  terms  of  time,  cost  and  effort,  and  the  statistical 
confidence  associated  with  the  estimate  (21:16).  The 
estimate  of  the  resources  required  to  complete  the  project  is 
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defined  in  terms  of  the  project  factor  data  (listed  above) 
(42:3-22) . 

Regarding  schedule.  Initial  inputs  into  the  SoftCost-R 
model  determine  how  SoftCost-R  will  determine  schedule. 
"Bstlmate  Date”  and  ”Project  Start  Date*  are  two  inputs  used 
to  compile  Gantt  and  PBRT  charts  (42:1-3).  Once  the  option 
of  either  Gantt  or  PERT  chart  is  selected,  the  model  will 
display  effort  and  duration  values  originally  input  at  the 
beginning  of  the  program  and  then  give  the  user  the 
opportunity  to  change  these  values  if  further  knowledge  is 
available  (42:3-30).  The  Gantt  and  PBRT  charts  are  geared  to 
DOD-STD  2167.  Another  option,  ”what-if”  has  the  capability 
of  displaying  the  effects  of  varying  the  schedule  on  a  given 
budget  and 'Vice  versa  (42-:  3-24). 

SPQR/20.  The  Software  Productivity,  Quality,  and 
Reliability  Bstimator  (SPOR/IO*^”*)  was  developed  in  1986  by 
Software  Productivity  Research,  Inc.  (39:1).  SP(}R/20  is 

designed  to  be  the  quick  estimator  version  of  this  0K>del. 

The  number  ”20”  represents  the  approximate  number  of  input 
variables  required  for  the  model's  predictions  (39:2). 

Features  of  SP(2R/20  include  prediction  of  schedule  by 
phase,  effort  and  costs  by  activity,  and  staff  sizes  (39:1). 
SPQR/20  will  also  predict  complete  development  cycles  from 
planning  through  delivery,  maintenance  and  enhancements  for 
five  years  after  delivery,  defect  levels  of  software 
projects,  defect  removal  efficiencies  of  reviews  and  tests. 
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and  the  quality  and  reliability  o£  the  delivered  8o£ti«are 
(39:1). 

SPOR/20  is  designed  to  estlaate  "all  o£  the  direct  labor 
applied  to  8o£tware  deveiopaent  and  Maintenance*  (39:2).  The 
£ollowlng  are  the  Major  activities  Included  in  8PQR/20 
estiMates: 

1)  Planning 

2)  RequlreMents 

3)  Design 

4)  Coding 

5)  Integration 

6)  Testing 

7 )  DocuMntat  i  on 

8)  HanageMsnt 

9)  Central  Maintenance 

10)  BnhanceMents  (39:3). 

Another  interesting  aspect  is  8P0R/20  uses  *£unction 
points*  to  predict  new  source  code  size.  The  Function  Point 
technique  %#a8  developed  in  1979  by  A.J.  Albrecht  o£  the  IBH 
Corporation  (39:50). 

Prior  to  the  Function  Point  technique,  8o£tware 
productivity  was  always  Measured  in  terMS  o£  lines 
of  code  such  as  cost  per  source  line  or  lines  of 
code  per  Man  Month.  Unfortunately,  this  Metric 
cannot  safely  be  used  for  high-level  languages, 
since  productivity  rates  in  llnes-o£-code  fora 
actually  aove  backward  as  real  productivity 
iaproves  (39:501. 

In  other  wrds,  there  are  soae  non-coding  efforts  that 
will  reaain  as  fixed  costs  in  person  Months  despite  the  use 
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o£  a  high-level  language  that  reduces  the  aaount  of  effort 

for  coding.  The  non-coding  efforts  are  requirenents,  design, 

docuMntation,  and  aanageMent.  Lines  of  source  code, 

coding,  and  integration  and  test  are  the  coding  efforts 

affected  by  the  use  of  a  high-level  language  (39:50).  As  in 

any  process  where  there  are  fixed  costs  involved,  when  there 

is  a  decline  in  the  nuaber  of  units  produced  (or  in  this  case 

a  reduction  in  lines  of  code  doe  to  use  of  a  high-level 

language),  the  cost  per  unit  (or  source  code)  aust  increase. 

The  Function  Point  technique  atteapts  to  compensate  for 

the  use  of  high-level  languages  by  placing  weights  on 

paraaeters  that  Albrecht  deterained  to  eabody  the 

functionality  of  a  prograa.  These  paraaeters  are:  nuaber  of 

inputs,  nuaber  of  outputs,  nuaber  of  inquiries,  nuaber  of 

data  files,  nuaber  of  interfaces  (39:51).  When  the 

paraaeters  are  weighted,  they  are  also  adjusted  for 

coaplexity  and  then  suaaed  to  derive  a  function  point  total 

(39:51).  This  Function  Point  value  is  input  into  the  aodel 

to  estiaate  new  source  lines  of  code. 

The  advantages  of  using  the  Function  Point  technique  as 

noted  by  the  developers  of  8PQR/20  are: 

1)  Function  Points  are  independent  of  source  code, 
and  do  not  penalized  high-level  languages;  2) 

Function  Points  can  be  applied  early  in  a  software 
life  cycle,  such  as  during  the  design  phase;  3) 

Function  Points  can  be  used  to  predict  source  code 
size  .  .  .  (39:511. 

The  disadvantages  of  the  Function  Point  technique  lie  in 
the  aabiguity  that  exists  in  defining  the  Function  Point 
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paraneters  and  the  subjectiveness  in  the  treatnent  of  the 
coisplexlty  adjustment  (39:51). 

Output  of  SPQR/20  covers  six  aspects  of  software 
development  programs.  The  first  output  is  a  risk  and  quality 
estimate.  Next,  is  a  defect  removal  and  reliability 
estimate.  Next,  are  the  main  development  and  maintenance 
cost  estimates.  Finally,  norskalized  management  information 
is  output. 

aystem-a.  System-3'^'^  is  a  software  cost  estimating 
model  developed  by  Computer  Bconomics,  Inc.  and  is  based  on 
%rork  done  by  Or.  Randall  Jensen  (13:1-1).  Dr.  Jensen 
explains  the  basic  equation  used  in  System-l  in  the  article 
"An  improved  Macrolevel  Software  Development  Resource 
'  Bstimation  Model".  Using  a  technology  constant  based  on 
technology  input  parameters  and  the  Rayleigh-Norden  curve, 
System-3  computes  the  required  software  developawnt  effort  in 
staff -months  and  dollars  (25:1). 

JS-1  and  JS-2  were  the  predecessors  of  System-3.  JS-1 
%fas  introduced  in  1982  after  3  years  of  development  by  CBI 
(13:1-3).  JS-2,  introduced  in  1984,  was  a  refinement  of  JS-1 

and  had  many  advantages  over  JS-1.  The  JS-1  produced 
estimates  for  the  Development  Phase  only  but  JS-2  also 
produced  estimates  for  the  Requirements  and  System 
Integration  Phases  (13:1-4).  Bach  parameter  is  further 
estimated  at  its  minimum,  most  likely  and  maximum  (13:1-4). 
CBI  purports  that  these  improvements  allow  users  to  estimate 
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even  their  uncertainty  and  further  Increase  overall 
estimation  accuracy  (13:1-4). 

Another  feature  of  JS-2  \ma  the  analysis  it  provides  for 
the  cost  and  schedule  required  to  "change,  enhance  and 
modify"  pre-existing  soft%nire  as  opposed  to  re-bulldlng  all 
new  (13:1-5). 

Finally,  JS-2  determined  cost  and  schedule  risk  for 
different  bidding  situations  from  fixed  price  bids 
(%rhere  a  higher  probability  of  completion  is 
required)  to  simpler  situations  where  "most  likely" 
estimates  are  needed.  These  features  were  firsts 
In  parametric  estimating  (13:1-5). 

In  the  spring  of  1986,  CBI  replaced  J8-2  with  a  new, 
further  Improved  product,  the  System-3  (13:1-5).  Some  of  the 
key  estimates  of  the  new  System-3  Include:  minimum 
development  time,  minimum  cost  within  a  schedule,  staffing 
projections  and  plans,  operational  support  costs,  project 
level  cost  summaries,  software  to  software  estimation, 
incremental  development  estimation,  system  conversion 
estimation  and  risk  evaluation  and  reduction 
(13:1-7).  System-!  will  also  generate  reports  on  schedule 
risk,  cost  risk,  dollars  by  month  and  differences  from 
baseline.  Finally,  System-3  can  generate  graphs  on  such 
areas  as  risk  analysis  and  effort  versus  schedule  tradeoffs 
(13:1-7). 

Inputs  Into  System-3  fall  under  the  following  four  basic 
parameter  categories:  size  or  source  lines  of  code  (SLOC), 
complexity,  development  capability,  and  environment  (13:1- 
11).  Minimum,  most  likely,  and  maximum  values  must  be  Input 
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for  each  factor.  Systea-S  also  requires  SLOC  Inputs 
(21:16). 

Regarding  schedule,  8ysteM-3  contains  a  "view  window" 
%rttlch  shows  %#hat  effect  a  change  In  an  Input  paraneter  will 
have  on  development  cost  and  schedule  (21:18). 

Outputs  of  System-3  consist  of  sussMiry  reports  of  effort 
(In  dollars  and  staff-months) .  Included  In  the  reports  are 
development  time,  the  computed  technology  constant,  and  the 
effective  size  (21:18). 
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III.  MBTHODOLOGY 


Introduction 

The  purpose  of  this  chapter  is  to  describe  the 
isethodology  that  will  be  used  to  arrive  at  answers  or 
conclusions  for  the  Investigative  Questions  posed  in  Chapter 
I.  The  Investigative  Questions  are  designed  to  go  from  the 
general  to  the  specific. 

Question  Qna 

What  are  the  factors  affecting  a  software  developaent 
program  schedule? 

This  question  will  be  answered  in  terns  of  the  vie%» 
experts  in  the  field  of  software  development  and  software 
engineering  have  toward  schedule  risk.  An  understanding  of 
these  views  regarding  schedule  risk  will  be  obtained  from 
reading  current  literature  in  the  form  of  books,  periodicals, 
and  professional  journals  on  the  subject.  A  particular 
journal,  the  Institute  of  Blectronic  and  Electrical  Bnoineers 
(IBBB)  Transactions  on  Software  Bnaineerina.  has  numerous 
articles  %rritten  by  experts  in  the  area  of  software 
development  and  is  published  monthly. 

Question  Two 

Vhat  is  the  importance  of  schedule  risk  to  a  software 
development  program? 

a)  To  %rhat  degree  do  program  managers  consider 
schedule  risk  when  estimating  the  cost  of  a 
software  development  program? 
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The  first  part  of  this  question  will  also  be  determined 
after  a  review  of  current  literature  written  by  experts  In 
the  field. 

The  sub-part  to  this  question  will  be  determined  after 
Interviewing  DOD  program  managers  and  experts  In  private 
Industry  who  have  been  Involved  In  software  development 
projects . 

An  interview  will  be  used  as  opposed  to  a  survey  because 
of  the  "depth  and  detail  of  the  Information  that  can  be 
secured*  (20:160).  Also  the  quality  of  the  Information 
should  be  better  than  If  obtained  by  a  survey  because  the 
Interviewer  "can  note  conditions  of  the  Interview,  probe  with 
additional  questions,  and  gather  supplemental  Information 
through  observation”  (20:160). 

Costliness  Is  one  disadvantage  of  Interviews  (20:161). 
Costliness  of  Interviews  will  not  be  a  factor  In  this 
research. effort  because  of  the  ease  of  reaching  program 
managers  located  on  the  same  base  (Vright-Patterson  APB). 
Reaching  program  managers  at  BSD  and  other  divisions  of  AFSC 
will  also  not  be  costly  because  they  will  be  Interviewed  via 
Autovon . 

When  Interviewing  program  managers  at  divisions  other 
than  ASD  located  at  Vright-Patterson  over  the  telephone, 
one  possible  limitation  should  be  considered.  The  length  of 
the  Interviews  may  not  be  as  long  as  those  conducted  at  ASD 


Interviews.  This  was  considered  when  evaluating  the  answers 
given  by  lntervle%rees . 

The  number  and  Identity  of  the  lntervle%rees  will  be 
determined  by  contacts  from  the  various  product  divisions  In 
Air  Force  Systems  Command.  Preferably,  the  number  to  be 
interviewed  should  be  at  least  five  program  managers  from 
each  Division  (total  of  t%#enty  program  managers).  This 
number  should  be  sufficient  to  cover  the  spectrum  of  views 
program  managers  have  regarding  schedule  risk  In  software 
development  programs  without  the  ansvrers  becoming  repetitive. 

The  questions  ranged  from  the  general  to  the  specific 
and  will  be  open-ended  type  questions.  Two  questionnaires 
were  used.  One  was  for  DOO  Program  Managers  and  Engineers 
and  the  other  was  for  Software  Development  Experts  (DOD  and 
Commercial).  The  exact  list  of  questions  was  determined 
after  a  review  of  literature  was  made.  Once  the  questions 
.were  determined,  they  were  reviewed  by  selected  AFIT  faculty 
and  colleagues  for  clarity  and  content.  The  lnterviet#er 
practiced  asking  the  questions  on  colleagues  before  the. 
actual  lntervle%rs  In  order  to  become  familiar  with  the 
questions.  The  questions  used  in  the  lntervle%ns  are  given  in 
Appendix  A  and  B. 

Queation.  Three 

Vhat  owthods  for  determining  schedule  risk  are  currently 
used  in  software  development  cost  models  and  have  they 
been  tested  and/or  validated? 

a)  Which  of  these  methods  appear  to  be  most  valid? 
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The  answer  to  these  Investigative  questions  was 
determined  from  an  analysis  of  selected  standard  software 
development  cost  models. 

The  selection  of  these  cost  models  was  based  on  the 
availability  of  documentation  on  exactly  how  these  models 
were  derived  and  availability  of  access  to  these  models  for 
generating  case  estimates.  Models  considered  for  use  %#ere: 

1)  constructive  COst  MOdel  (COCOMO)  (5:29), 

2)  PRICB-S  (34:1-1), 

3)  Putnam-SLIM  (31:1-1). 

4)  Systems-3  (13:1-1). 

5)  SoftCost-R  (42:1-1). 

6)  SPQR-20  (39:1-1). 

These  cost  models  %rere  discussed  previously  in  the  Background 
section  of  Chapter  I  and  extensively  in  Chapter  II. 

The  analysis  of  these  cost  models  %ra8  sufficient  to 
determine  how  schedule  risk  was  incorporated  into  these 
models  and  what  comprises  schedule  risk. 

Historical  cost  data  on  software  development  programs 
conducted  in  the  DOD  was  run  on  the  models  and  a  comparative 
analysis  of  the  estimates  given  by  each  model  was  made. 

Also,  each  estimate  was  compared  to  the  actual  cost  of  the 
software  development  program  that  generated  the  data  to 
determine  their  accuracy. 
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In  cost  Models,  «rhat  Is  the  significance  of 
schedule  risk? 

a)  Is  schedule  risk  an  Independent  variable  or 
does  Its  significance  depend  on  the  value  of 
other  Independent  variables  In  the  cost  models 
such  as  size  of  the  program,  number  of 
programmers  required,  or  level  of  software 
sophistication  required? 

The  answer  to  this  Investigative  Question  was  also 
determined  by  reviewing  the  answers  given  by  program  managers 
and  experts  In  the  field  to  the  questionnaire  and  by 
analyzing  the  selected  cost  models  and  reviewing  the 
available  documentation  on  the  regression  techniques  used  to 
derive  these  models. 


Question  Five 

Can  any  of  these  methods  be  combined  or  Incorporated 
into  a  new  and  more  accurate  method  for  accounting  for 
schedule  risk  In  cost  models? 

The  answer  to  this  investigative  question  was  derived 


from  a  culmination  of  the  answers  to  the  Investigative 
questions  above. 


IV.  Findings 


Introduction 

The  purpose  of  this  chapter  is  to  discuss  the  findings 
of  this  research  and  to  discuss  the  answers  to  each  of  the 
investigative  questions  posed  in  Chapter  III.  Each  of  the 
investigative  questions  are  addressed  independently; 
findings  from  this  research  relate  to  nore  than  one 
investigative  question. 

Question  One 

What  are  the  factors  affecting  a  software  development 

program  schedule? 

Introduction.  Frederick  P.  Brooks,  Jr.,  author  of  Ihs. 
Mythical  Man-Month,  states,  "Most  software  projects  have  gone 
a%n:y  for  lack  of  calendar  time  than  for  all  other  causes 
combined"  (7:14).  This  regard  for  the  effects  that  a 
schedule  can  have  on  a  software  development  program  seems  to 
be  universal  among  experts  in  the  field.  Therefore,  it  is 
Important  that  the  factors  affecting  schedule  should  be 
identified  so  that  steps  to  control  these  factors  can  be 
taken. 

Chapter  III  stated  that  the  answer  to  this  question  was 
determined  from  analyzing  the  views  of  the  leading  experts  in 
the  field  of  software  development  estimation.  The  experts' 
views  were  found  by  researching  articles  and  conference 
papers  found  in  common  professional  journals  and  articles  of 
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the  software  engineering  field.  Books  and  tutorials  by  noted 
software  development  experts  were  researched  as  well.  The 
general  conclusion  Is  there  are  many  factors  that  go  Into  the 
estimate  of  a  software  development  program,  and  the  answer  to 
this  question  can  be  as  broad  as  the  entire  software 
development  program  estimation  process  Itself.  This  section 
will  begin  with  a  discussion  of  the  views  of  the  experts 
examined  in  this  research.  Next,  their  views  will  be 
summarized,  and  finally  conclusions  will  be  drawn  from  the 
summary. 

Software  Development  Phases.  Before  discussing  the 
factors  Involved  in  the  estimation  of  a  software  development 
program,  a  review  of  the  broader  topic  of  the  software 
development  life  cycle  Is  appropriate.  As  noted  In  Chapter 
II,  DOD-STD  2167  gives  a  very  complete  description  of  all  the 
phases  of  the  software  development  life  cycle.  These  phases 
are.  In  order  of  earliest  to  latest:  System  Requirements 
Analysis/Design,  Software  Requirements  Analysis,  Preliminary 
Design,  Detailed  Design,  Coding  and  Computer  Software  Unit 
Testing,  CSC  Integration  and  Testing,  CSCI  Testing,  and 
System  Integration  and  Testing  (16:9). 

Many  experts  break  down  factors  that  are  used  In 
software  development  program  estimation  by  life  cycle  phase 
and  others  still  will  group  the  factors  by  the  more  general 
headings  of  "product  related  factors"  or  "process  related" 
factors".  J.D.  Aron  reports  that  the  System  Development 
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Corporation  in  the  Programming  Management  Project  spent  years 
analyzing  data  to  Identify  factors  affecting  a  program's 
schedule  (2:262).  They  concluded  that  key  variables  fall 
into  three  groups:  uniqueness,  development  environment,  and 
job  type  and  difficulty  (2:262). 

Another  expert,  Stephen  P.  Kelder,  identifies  projects 
as  having  five  distinct  phases:  pre-lnitlatlon  period, 
initiation  period,  project  duration,  project  termination,  and 
post-termination  period  (26:53).  Kelder  identifies  various 
factors  that  occur  in  each  phase  that  can  affect  schedule. 
Still  another  expert,  Alan  J.  Driscoll,  describes  the 
software  development  process  in  three  stages:  analysis  and 
design,  implementation,  and  verification  (19:46).  Finally, 
William  S.  Donelson  has  yet  another  idea  of  what  the  phases 
of  the  life  cycle  of  a  software  development  program  should 
be.  He  says  the  life  cycle  has  the  following  nine  phases: 
problem  definition,  project  organization,  problem  analysis, 
system  definition,  system  review  and  approval,  detail  design, 
programming  and  testing,  training  and  implementation,  and 
post-implementation  review  (17:74-75). 

The  point  here  is  that  although  the  standard  for 
software  development  programs  with  the  DOD  is  DOD-STD  2167, 
phases  of  this  life  cycle  may  have  other  slightly  different 
titles  or  certain  phases  may  be  combined  into  a  larger 
singular  phase  in  private  industry.  This  may  be  confusing  to 
some  when  trying  to  Identify  which  phases  of  the  life  cycle 
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are  associated  with  which  factors  that  affect  schedule. 

Also,  another  problem  that  may  arise  from  this  Is  that 
parties  Involved  In  a  software  development  effort,  because 
they  have  different  definitions  for  the  phases  of  the 
software  development  life  cycle,  may  also  have  different 
Ideas  for  where  critical  events  In  the  software  development 
life  cycle  should  occur. 

For  this  research  effort,  the  life  cycle  phases 
described  In  DOO-STD  2167  will  be  used.  Also,  If  factors  are 
grouped  In  the  discussion,  they  will  be  grouped  by  the 
categories  Identified  In  the  COCOMO  estimation  model.  Those 
categories  are:  size  attributes,  product  attributes, 
computer  attributes,  personnel  attributes,  and  project 
attributes  (6:502).  The  following  section  discusses  each 
factor  found  by  various  experts  to  affect  software 
development  program  schedule. 

Lines  of  code.  As  Putnam  (who*  Is  well  known  for 
developing  the  SLIM  estimation  model)  states,  "The  earliest 
efforts  at  software  cost  estimation  arose  from  .  .  . 
measuring  average  productivity  rates  for  workers  (30:11).  An 
estimate  of  the  total  job  was  made  by  compiling  these  rates. 
The  estimate  was  "usually  In  machine  language  Instructions" 
also  kno%m  as  "lines  of  code"  (30:11).  Machine  language 
Instructions  were  used  In  early  years  because  the  factor  was 
related  to  memory  capacity  "which  was  a  severe  constraint 
with  early  machines  (30:11).  To  determine  the  schedule  of 
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the  project,  one  merely  took  the  project  estimate  in  machine 
language  instructions  and  divided  it  by  the  budgeted  manpower 
(30:il).  Putnam  adds  that  if  this  method  produced  a 
schedule  that  was  unacceptable  to  the  user  then  "the  manpower 
level  (and  budget)  was  increased  until  the  time  to  do  the  job 
met  the  contract  delivery  date"  (30:ii). 

The  constraint  of  memory  capacity  is  not  a  big  problem 
with  the  computers  used  today  for  software  development 
programs.  Brooks  has  shown  in  his  book.  The  Mythical  Man- 
Month.  that  adding  manpower  to  a  software  project  will  not 
decrease  its  schedule  (especially  if  it  is  already  over 
schedule),  but  it  will  in  fact  increase  schedule  (7:19). 

For  these  reasons,  the  number  of  lines  of  code  a  software 
program  is  expected  to  contain  does  not  appear  to  be  a  good 
determinant  by  itself  of  what  the  software  development 
program  schedule  will  be. 

Putnam  adds  to  this  conclusion  by  saying  that  most 
program  managers  do  not  have  a  good  idea  of  how  to  estimate 
how  many  lines  of  code  a  program  will  take  anyway.  He  says 
that  estimating  size  "has  largely  been  an  intuitive  process 
in  which  most  estimators  attempt  to  guess  the  number  of 
modules  and  the  number  of  statements  per  module"  (32:1). 
Putnam  contends  that  this  may  be  an  effective  way  to 
estimate  small  projects  (less  than  10  person  years  of 
effort),  but  using  this  method  on  large  projects  has  been 
proven  ineffective  (32:1).  Wendt  and  Evans  agree  with 
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Putnaa's  beliefs  and  say  that  the  prograsswrs  will  not  be 
mich  help  %rhen  estimtlng  lines  of  code  for  a  prograa 
either. 

First  of  all,  BK)st  prograMsers  do  not  know  how  to 
estiMte  lines  of  code,  and  wonder  «rhat  it  has  to 
do  with  anything,  anyway.  PrograwMrs  do  not  want 
to  code  the  sasM  application  over  and  over  again, 
and  before  they  get  to  the  point  idiere  they  could 
tell  you  how  Many  lines  of  code  a  particular 
application  will  take,  they  have  requested  to 
change  areas  or  even  Moved  to  another  coMpany 
looking  for  a  different  soft%fare  challenge 
(45:10581 . 

Hendt  and  Evans  also  point  out  that,  tdiile  counting 
lines  of  code  appears  to  not  be  a  very  efficient  way  of 
estlMatlng  the  size  of  a  soft%fare  prograM,  there  is  no  other 
convenient  Measure  available  and  subsequently  this  paraMSter 
persists  (45:1058). 

As  a  counter  arguMent  to  these  beliefs  that  the  nuMber 
of  lines  of  code  Is  not  a  good  predictor  of  schedule,  Roger 
S.  PressMan,  author  of  flofti^re  Engineering:  A 
Practitioner’s  Approach,  states  that  a  prograM  of  large  size 
could  be  a  good  predictor  of  a  longer  schedule  because  "as 
size  increases,  the  interdependency  aMong  various  eleMents  of 
the  software  grows  rapidly”  and  subsequently  It  becoMes 
difficult  to  break  the  software  down  into  More  Manageable 
eleMents  (29:81). 

B^qniri*— nafinlt^on.  Many  experts  in  the  field  of 
software  developMent  contend  that  this  factor  is  one  of  the 
Most  critical  to  a  successful  software  developMent  prograM 
which  is  coMpleted  on  tlMs  and  at  target  cost.  Yet,  Phillip 
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Bruce  and  Sam  M.  Pederson,  authors  o£  The  Software 
Development  Project;  Planning  and  Management,  say,  "less 
effort  is  often  devoted  to  the  Initial  requirements 
definition,  costing,  and  scheduling  of  a  project  than  any 
other  part  of  the  development  cycle"  (8:16).  Wlngrove 
states  that,  "For  anything  other  than  a  very  small  or  simple 
project,  this  perfect  requirements  document  is  an 
impossibility"  (46:4). 

Requirements  for  the  software  program  are  specified  by 

the  user  in  the  System  Requirements  Analysis/Design  phase  of 

the  software  development  life  cycle.  At  this  time,  the  user 

tells  the  developer,  as  precisely  as  he/she  can,  what  the 

software  program  must  do.  Many  have  found  that  undesirable 

consequences  such  as  delays  in  schedule  result  when  the  user 

is  not  closely  Involved  in  the  requirements  definition 

process.  Wolverton  emphasizes  this  point  when  he  states. 

Thorough  and  continuous  involvement  of  the  customer 
in  the  development  process  has  been  a  reality  of 
several  large  software  developments.  Nothing  ta)ces 
the  place  of  competence  and  communication  when  it 
comes  to  understanding  the  customer's  or  sponsor's 
requirements  (47:1761. 

Wolverton  also  points  out  that  translating  total  system 
requirements  is  a  crucial  first  step  in  any  software 
development  project  (47:176). 

Driscoll  explains  the  effect  a  requirements  definition 
that  is  not  thorough  or  complete  can  have  on  software 
development  schedule. 
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The  effects  of  an  adequate  or  Inadequate 
requirements  analysis  or  definition  ripple  through 
all  phases  of  software  development.  Including 
design.  Changes  in  requirements  cause  changes  in 
design  and  these  in  turn  usually  cause  schedule 
changes  [19:471. 

It  is  evident  from  this  statement  that  it  is  not  exactly  the 

poor  requirements  definition  itself  that  will  cause  a 

schedule  to  slip;  instead,  it  is  the  inevitable  changes  that 

will  occur  later  in  the  software  development  life  cycle 

because  of  the  poor  definition  that  cause  schedules  to  fall 

behind.  Edmund  B.  Daly  states, 

.  .  .  historical  analysis  of  completed  GTE 
Automatic  Electric  Laboratories'  projects  Indicates 
that  over  50  percent  of  all  development  hours  are 
spent  correcting  bugs  which  result  from  faulty 
design  [15:2941. 

Putnam  also  believes  that  changes  in  the  requirements 
will,  if  not  initially,  eventually  affect  the  schedule  in 
disproportionately  large  amounts  (33:79).  He  gives  an 
example  with  the  Army  Computer  Systems  Command  data  where  a 
program  had  a  small  change  in  the  requirements  which 
resulted  in  a  major  change  in  the  schedule  a  year  later 
(33:79).  Putnam  states,  "This  shows  that  even  a  modest 
perturbation  of  the  system  can  have  definite  effects  on  large 
systems,  and  that  these  effects  may  not  be  apparent  until  a 
much  later  time"  (33:79). 

Bruce  and  Pederson  emphasize  that  spending  extra  time 
firming  up  the  requirements  before  the  Detailed  Design  Phase 
can  actually  shorten  the  overall  time  and  decrease  the  costs 
required  for  the  software  development  program  (7:17).  They 


46 


contend  that  the  regulreiMnts  definition  is  "the  basis  for 
the  analysis  of  many  other  costing  factors,  including 
difficulty,  interfaces,  size,  tools,  use  of  existing  software 
and  data  base  complexity"  (7:17).  Wendt  and  Bvans  agree 
with  this  statement  when  they  state,  "Software  managers  are 
forced  to  derive  complete  sizing  of  software  systems  based  on 
incomplete  requirements  and  system  specifications" 

(45:1058) . 

At  times,  the  requirements  definition  may  be  well 
specified  in  the  beginning,  but  there  are  still  changes  in 
the  requirements  during  the  software  development  life  cycle. 
This  occurrence  brings  to  light  another  factor  that  is 
related  to  requlreoMnts  definition  and  will  also  affect 
schedule,  which  is  termed  as  the  "stability  of  the 
requirements."  This  factor  is  not  discussed  as  frequently  in 
literature  probably  because  it  is  so  closely  related  to 
requirements  definition.  No  matter  how  detailed  the 
requirements  are  defined,  if  they  are  not  stable,  changes  In 
these  requirements  will  result  in  schedule  slippage.  Many 
experts  contend  that  if  the  requirements  are  not  stable  and 
there  are  major  changes  during  the  development  cycle,  the 
schedule  should  be  discarded  and  a  new  one  estisated  as  if  a 
new  softiraire  development  program  is  being  started. 

Prom  this  discussion,  it  is  surmised  that  adequately 
defining  the  requirements  of  a  software  development  program 
is  a  factor  that  has  a  major  affect  on  software  development 
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schedule.  Adequately  defined  requirements  will  allow  the 
estimator  to  more  accurately  predict  the  schedule  of  a 
development  program. 

Complexity.  A  general  definition  for  complexity  Is  the 
degree  of  difficulty  of  a  given  kind  of  software  routine 
(47:166).  Complexity  Is  typically  associated  with 
productivity  in  generating  lines  of  code.  It  is  commonly 
believed  that  the  more  complex  a  program,  the  more  lines  of 
code  It  will  take  and,  thus,  productivity  will  be  slower. 
Putnam  agrees  that  complexity  has  an  effect  on  productivity. 
After  examining  very  large  soft%»re  programs  which  required 
hundreds  of  lines  of  code  to  complete,  he  contended  "it 
became  apparent  that  severe  departures  from  constant 
productivity  rates  were  present  and  that  the  productivity 
rate  was  some  function  of  the  system  complexity"  (30:ii). 

Wolverton  contends  that  determining  the  degree  of 
complexity  (not  defining  the  requirements,  as  others  have 
stated)  of  a  software  program  is  "the  most  crucial  step  in 
the  estimating  process,  for  it  establishes  the  cost  of  the 
routine  with  all  direct  and  indirect  changes  amortized 
against  it"  (47:166).  In  other  words,  knowing  how  complex  a 
program  will  be  will  give  a  better  clue  as  to  how  many  lines 
of  code  the  program  will  take.  Boehm  states  that,  "Some 
studies  have  lumped  a  wide  variety  of  effects  into  the 
'complexity*  attribute  and  obtained  relatively  high 
productivity  ranges  as  a  result  .  .  ."  (6:505).  This  shows 
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that  what  determines  the  degree  of  complexity  of  a  program  Is 
very  judgmental.  While  It  Is  apparent  by  many  that 
complexity  of  a  program  does  have  an  effect  on  that 
program's  development  productivity  and  subsequently  Its 
schedule,  it  Is  still  difficult  to  pinpoint  how  to  define  a 
software  program  as  being  complex. 

Work  Breakdown  Structure  (WBS).  Many  experts  believe 
that  the  existence  of  a  Work  Breakdown  Structure  in  a 
software  development  program  Is  vital  to  that  program  staying 
on  schedule.  Pressman  states,  "The  degree  of  project 
structure  also  has  an  affect  on  estimation  risk"  (29:81).  He 
refers  to  structure  as  to  the  ease  with  which  a  program  can 
be  broken  down  Into  a  WBS  or  "compartmentalized"  (29:81). 
Bruce  and  Pederson  state  the  central  theme  of  their  book  is 
that  "all  software  projects  .  .  .  should  be  planned  and 
managed  along  structured  guidelines"  (7:1).  Having 
structure  to  a  software  development  program  is  the  primary 
reason  many  experts  stress  that  a  successful  software  project 
will  have  a  complete  WBS. 

Wendt  and  Evans  say,  "Assembling  the  specific  production 
tasks  into  a  WBS  is  the  heart  of  the  structure  which  will  be 
used  for  cost  and  schedule  control  (45:1060).  They  go  on  to 
say  that  because  the  product  tasks  cannot  be  identified  in 
detail  at  the  beginning  of  a  program,  the  estimator  must  rely 
on  the  WBS  to  develop  early  estimates  of  cost  and  schedule 
(45:1060) . 
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Paul  Rook  gives  a  good  explanation  of  the  Importance  of 

a  VBS  to  a  software  development  program: 

The  clear  emphasis  In  the  modern  approach  to 
software  engineering  Is  to  focus  attention  on  the 
overall  development  process.  This  Is  the  aim  of 
structured  soft%(are  development  which  breaks  down 
the  project  Into  a  series  of  distinct  phases,  each 
with  well  defined  goals,  the  achievement  of  which 
can  be  verified,  ensuring  a  sound  foundation  for 
the  succeeding  phase.  It  also  breaks  down  the  work 
to  be  performed  Into  a  series  of  discrete 
manageable  packages,  and  creates  the  basis  for  the 
appropriate  organisational  (sic]  structure.  This 
allows  overall  planning  of  'how'  the  software  Is 
going  to  be  developed  as  well  as  considering  'what* 
is  going  to  be  developed  as  the  product  (37:71. 

Howes  also  advocates  decomposition  of  the  software 

development  Into  "work  packages"  which  he  says  can  be  managed 

from  beginning  to  end  by  one  person.  He  says  once  the 

components  are  broken  down  to  this  level  in  the  VBS,  then 

estimation  should  take  place  for  each  component  (23:26). 

Finally,  Howes  says,  "The  schedule  for  your  project  is  the 

composite  of  all  work  package  schedules"  (23:29).  Bruce  and 

Pederson  agree  with  this  when  they  say  by  structuring  the 

program,  one  can  "reduce  the  estimating  task  to  a  large 

number  of  more  precise  estimates  rather  than  a  single  task" 

(7:20) . 

Jack  Cooper  contends  that  partitioning  Into  smaller 
packages  allows  managers  to  avoid  "having  to  resort  to 
percentages  in  status  tracking"  because  partitioned  packages 
will  be  small  enough  that  "they  can  be  considered  either  not 
started  or  completed  (0  to  100%  complete)"  (14:24). 
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The  size  o£  these  "discrete  manageable  packages"  and 
adding  the  schedules  for  each  package  together  to  get  a  full 
schedule  has  been  the  subject  of  some  discussion  in 
literature . 

Brooks  has  said,  and  many  in  the  field  seem  to  agree, 
that  by  continuing  to  partition  a  program  Into  smaller  and 
smaller  components.  In  order  to  have  the  work  progress  more 
quickly  by  adding  more  programmers,  does  not  always  work 
(7:19).  Brooks  states. 

Since  software  construction  is  inherently  a  systems 
effort  -  an  exercise  in  complex  interrelationships 
-communication  effort  is  great,  and  it  quickly 
dominates  the  decrease  in  individual  task  time 
brought  about  by  partitioning.  Adding  more  men 
then  lengthens,  not  shortens,  the  schedule  [7:19]. 

The  key  here  is  communication.  Brooks  believes  that 

many  tasks  that  are  partitioned  still  require  communication 

among  other  sub-tasks  In  order  to  be  completed  (7:17).  This 

extra  effort  in  communication  more  than  offsets  any  gain  in 

schedule  that  might  be  had  by  partitioning  the  tasks  in 

order  to  add  more  programmers  to  development  program. 

Another  point  that  Brooks  makes  is  that  a  task  by  itself 

has  a  probabilistic  effect  on  schedule  (7:14).  When  that 

task  is  partitioned  into  smaller  sub-tasks,  each  of  these 

sub-tasks  also  have  a  probabilistic  effect  on  schedule. 

When  these  sub-tasks  are  chained  together  to  form  the  task, 

"the  probability  that  each  will  go  well  becomes  vanishingly 

small"  (7:14). 
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In  summary,  having  a  WBS  can  help  to  predict  the 
schedule  o£  a  software  development  program  in  its  beginning. 
However,  there  is  a  point  at  which  further  partitioning  of 
tasks  in  a  WBS  may  work  to  lengthen  a  schedule  rather  than 
shorten  it.  This  is  due  to  the  problems  of  communication 
required  between  the  programmers  and  the  greater  probability 
of  more  errors  within  each  task. 

Amount  of  Prior  Planning  Performed.  Another  factor 
somewhat  related  to  the  WBS,  and  stated  by  many  experts  as 
having  an  inverse  affect  on  software  development  schedules, 
is  the  amount  of  prior  planning  performed.  Cooper  states, 
'*The  lack  of  comprehensive  planning  prior  to  the  initiation 
of  a  software  development  project  is  a  very  pervasive 
falling"  (14:22). 

A  good  software  development  plan.  Cooper  says,  will 
contain  "a  description  of  the  development  organization,  the 
technical  approach,  the  milestones  and  schedules,  and  the 
allocation  of  resources"  (14:22).  The  benefits  of  an 
adequate  plan  include  "providing  the  developer  with  the  means 
to  coordinate  schedules,  control  resources,  initiate  actions, 
and  monitor  progress  of  the  development  effort"  (14:22). 

Rook  states  a  good  plan  is  based  on  the  WBS  which  is  produced 
during  the  work  definition  process  (37:9). 

As  stated  earlier,  the  results  of  Inadequate  planning 
can  be  disastrous.  Wendt  and  Evans  say  inadequate  planning 
can  result  in  "a  pattern  of  unanticipated  project  activities 
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and  frequent  unplanned  development  catastrophes  and  crises" 
(45:1055) . 

After  analyzing  the  planning  factor.  It  Is  evident  that 
if  the  software  development  program  has  no  plan  or  a  poor 
plan  from  its  onset,  the  estimator  can  assuredly  add  many 
more  person-months  to  the  schedule  estimate. 

Software  Development  Standards.  Software  development 
standards  (sometimes  called  software  metrics)  are  standards 
for  development  practices  that  have  been  documented  as 
occurring  on  past  software  development  projects  (29:82). 

Many  experts  believe  schedules  can  be  predicted  more 
accurately  if  standards  that  have  woriced  in  the  past  are 
used  on  current  projects.  Pressman  emphasizes  this  belief  in 
the  following  statement: 

By  looking  back  we  can  emulate  things  that  worked 
and  improve  areas  where  problems  arose.  When 
comprehensive  software  metrics  for  past  projects 
are  available,  estimates  can  be  made  with  greater 
assurance,  schedules  and  overall  risk  can  be 
reduced  [29:821. 

Using  standards  may,  in  fact,  improve  the  prediction  of 
schedules,  but  the  problem  lies  in  the  availability  of  these 
standards.  As  Wolverton  states,  "There  are  virtually  no 
objective  standards  or  measures  by  which  to  evaluate  the 
progress  of  computer  program  development"  (47:156).  Bruce 
and  Pederson  agree  when  they  say,  "  The  second  major  problem 
in  estimating  software  development  costs  is  the  lack  of 
accurate  measures  of  prior  costs  .  .  ."  (7:17).  They  also 
believe  that  "without  reference  standards  it  is  nearly 
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impossible  to  accurately  estimate  the  cost  of  a  new  project" 
(7:17)  . 

In  conclusion,  it  is  commonly  agreed  that  standards, 
when  available,  will  enhance  the  ability  to  accurately 
predict  schedule. 

Use  of  Management  Principles.  Another  factor  that 
experts  have  mentioned  in  literature  and  is  related  to 
software  development  standards  is  the  use  of  management 
principles.  Surprisingly,  experts  often  mention  software 
projects  as  having  failed  simply  because  there  were  no 
standard  management  principles  or  policies  existing  to  guide 
the  project.  Thayer  and  Pyster  commented  that,  in  the  1960s 
and  early  1970s,  "chaos"  existed  in  software  development 
primarily  because  managers  had  no  systematic  approach 
available  to  them  for  managing  large  software  projects 
(40:2).  Thla  time  of  chaos  is  past,  and  today  there  is  a 
more  widespread  use  of  standard  management  principles  for 
managing  software  development  projects.  Thayer  and  Pyster 
state. 

Since  1970  great  strides  have  been  made  in 
understanding  how  the  manage  large  software 
development  projects.  There  have  been  many 
successful  deliveries  of  major  defense  and  space 
systems;  perhaps  the  most  well-lcnown  of  the  1980 's 
is  the  Space  Shuttle  software  for  NASA  [40:21. 

Thayer  and  Pyster  also  state  that  TRW,  Inc.  (a  leader  in 

the  software  development  Industry)  requires  project  managers 

of  large  projects  to  follow  a  standard  set  of  software 

development  policies  (40:2).  Finally,  Thayer  and  Pyster 
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comment  that  current  advances  in  management  science  can  be 
applied  as  management  principles  for  software  development 
projects,  particularly  in  the  area  of  scheduling  (40:2), 

T.K.  Abdel-Hamld  and  S.E.  Madnlcic  developed  a  model  that 
helps  software  development  project  managers  decide  when  to 
use  particular  management  principles  and  tools  (1:15). 

Through  their  research,  Abdel-Hamid  and  Madnlcic  found  that, 
in  software  development  projects,  a  "feedback  loop"  similar 
to  Figure  I  exists  (1:19).  They  explain  through  various 
techniques  an  estimate  is  produced,  and  from  this  estimate  a 
schedule  is  developed.  This  schedule  is  then  the  basis  for 
management  actions  and  these  actions  or  principles  used 
affect  worker  performance.  Worker  performance  is  the  input 
for  future  estimates  and  the  loop  starts  again  (1:19). 

Figure  I 

Software  Development  Project  Feedback  Loop  (1:19) 


Abdel-Hamid  and  Madnlck's  point  is  that  "knowledge  of 
project  schedules  was  found  to  affect  the  real  progress  rate 
that  is  achieved"  (1:19).  They  also  say  that  all  the 
dynamics  of  this  loop  affect  the  schedule  of  a  software 
development  program;  therefore,  they  conclude  scheduling  is 
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not  just  producing  better  estlMtes  but  enconpasses  a  whole 
host  of  other  nanagenent  problems  requiring  the  use  of 
management  principles  as  %iell  (1:19). 

Volverton  says  that,  at  TRW,  they  have  established  five 
management  principles  that  "apply  throughout  the  software 
developownt  cycle  to  reduce  the  problem  of  control  to 
manageable  size"  (47:157).  These  principles  deal  with:  1) 
Producing  adequate  software  documentation  that  aanagement  can 
use  to  control  the  project;  2)  Conducting  technical  reviews 
to  acquire  customer  approval  of  the  software  criteria  before 
a  schedule  is  developed;  3)  Controlling  the  software 
physical  media  to  "assure  use  of  a  Icnown  configuration" 
throughout  the  development  life  cycle;  4)  ^plication  of 
soft%«re  configuration  management,  controls  and  procedures; 

5)  Developing  a  data  reporting,  repository,  and  control 
system  for  use  by  developer  and  user  (47:157).  These 
principles  would  be  a  good  basis  for  other  software 
developers  when  establishing  their  own  management  principles. 

Software  Prnair^mmmmr  MHtm-y-  Hany  experts  believe  that 
there  are  characteristics  about  the  person  programming  the 
software  and  characteristics  about  the  software  that  relate 
to  the  programmer  that  affect  the  software  developawnt 
program.  Aron  believes  that  such  factors  as  programmer  or 
programming  team  familiarity  with  the  "hardware,  software, 
and  subject  matter  of  the  project"  will  affect  the  schedule 
of  the  development  program  (2:262).  Aron  also  says  the 
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development  environment  in  which  the  programmers  must  work 
will  affect  productivity.  If  the  environment  contributes  to 
poor  communication  because  of  dispersion  of  the  programmers 
or  if  the  facilities  are  unpleasant,  costs  will  increase  due 
to  reduced  productivity  (2:262). 

Keider  says  one  misconception  estimators  have  when 
rating  the  ability  of  a  programmer  at  the  beginning  of  a 
software  development  program  is  that  programmers  are 
considered  "universally  expert"  and  to  be  equally  competent 
"analysts,  designers,  programmers,  librarians,  and 
documentation  specialists"  (26:55).  Program  Managers  will 
assign  any  of  the  functions  to  the  programmer  with  little 
regard  for  the  programmer's  ability  and  "Invariably,  this 
results  in  project  delay"  (26:55). 

Boehm  circumvents  this  rating  of  the  individual 
programmer  by  saying,  "the  important  attribute  to  rate  is  not 
average  individual  .  .  .  programmer  capability,  but  the 
effective  .  .  .  programmer  team  capability"  (6:509).  He 
prefers  also  to  include  in  the  rating  such  non-tangible 
factors  as  "team's  cohesiveness,  communicativeness,  and 
motivation  toward  group  versus  individual  achievement"  in  the 
programmer  rating  (6:509). 

Statements  made  by  experts  in  the  software  development 
field  suggest  that  accurately  rating  the  programmer  and 
programmer  team  is  Important  when  attempting  to  accurately 
predict  the  schedule  of  a  program.  The  problem  occurs  when 
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trying  to  quantify  factors  such  as  motivation  that  are 
difficult  to  Identify  on  the  surface. 

Data  Base  Requirements.  Data  base  requirements  occur  as 
a  result  of  the  outputs  (reports,  cathode  ray  tube  (CRT) 
screens,  audio  response,  graphics,  etc.)  the  user  requires  of 
the  software  development  program.  As  Donelson  states  once 
the  user  has  defined  the  reporting  requirements,  "the  systems 
analyst  must  then  determine  the  data  base  requirement  to 
support  this  reporting  capability"  (17:73).  Donelson  also 
urges  the  user  to  "participate  aggressively  In  this  data 
base  definition  activity"  to  ensure  an  acceptable  product 
(17:73). 

Boehm  says  the  factor  to  be  considered  Is  really  the 

"overall  size  of  the  data  base  to  be  designed,  assembled,  and 

validated  prior  to  acceptance"  (6:502).  He  also  states. 

Relatively  little  has  been  determined  about  the 
effect  of  this  factor.  The  Doty  study  indicated  It 
had  a  'minor'  effect,  but  no  quantitative  data  were 
given.  The  Air  Force  Industry  Software  Cost 
Estimation  Workshop  considered  It  an  Important 
factor  but  provided  no  estimates  on  the  magnitude 
of  Its  effect  (6:5041. 

Prom  a  review  of  the  literature  it  Is  evident  that 
several  experts  see  the  data  base  requirement  as  affecting 
the  software  development  effort,  but,  as  of  yet,  no 
conclusive  evidence  exists  to  show  the  extent  of  the  effects. 

Allowance  for  Testing.  This  factor  describes  the  amount 
of  time  allowed  In  the  life  cycle  for  System  Integration  and 
Testing.  Ideally,  if  the  software  program  Is  developed 


58 


correctly  and  perfectly,  the  amount  of  time  required  for 

testing  and  debugging  should  be  zero;  however,  this  is  never 

the  case.  Brooks  elaborates. 

No  parts  of  the  schedule  are  so  thoroughly  affected 
by  sequential  constraints  as  component  debugging 
and  system  test.  Furthermore,  the  time  required 
depends  on  the  number  and  subtlety  of  the  errors 
encountered.  .  .  .  Because  of  optimism,  we  usually 
expect  the  number  of  bugs  to  be  smaller  than  it 
turns  out  to  be.  Therefore,  testing  is  usually  the 
most  mis-scheduled  part  of  programming  [7:19]. 

Donald  J.  Reifer,  developer  of  the  SoftCost-R  software  cost 

estimation  model,  says  that  one  component  of  a  sound 

technical  approach  to  software  development  is  that  adequate 

attention  be  placed  on  testing  (35:126). 

There  are  tools  currently  available  to  assist  in 

detecting  errors  in  software  and  assist  in  making  the  test 

phase  of  the  life  cycle  as  efficient  as  possible.  However, 

as  Wlngrove  notes,  "Reports  of  a  lack  of  discipline  on  test 

methods  and  metrics  can  have  catastrophic  consequences  for 

interfacing  and  Integration"  (46:5).  This  in  turn  could  lead 

to  further  schedule  delay. 

The  main  point  regarding  test  is  that  it  should  not  be 
optimistically  shortened  when  developing  the  development 
program  schedule;  but  instead,  it  should  be  realistically 
lengthened.  Also,  tools  to  aid  in  testing  should  be  used  to 
increase  efficiency. 

Use  of  Software  Development  Tools.  As  mentioned  above, 
several  experts  believe  the  use  of  software  tools  may 
increase  efficiency  in  the  test  phase  of  software 
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development,  but  many  experts  believe  that  using  software 
tools  may  also  Increase  productivity  in  other  phases  of 
software  development. 

Rook  states,  "The  earliest  tools  were  concerned  with  the 

production  of  code"  (37:7).  Today,  however,  there  are  many 

more  tools  available  to  the  developer  that  will  assist  in 

"specification,  design,  estimating,  planning,  documentation 

and  configuration  management"  (37:7).  Bruce  and  Pederson 

highlight  the  importance  of  software  development  tools. 

Vith  the  recent  gro%/th  in  the  number  of 
minicomputer  -  and  microprocessor  -  based  systems 
being  developed,  this  factor  has  become 
increasingly  important.  The  cost  estimator  must 
consider  how  the  software  will  be  developed, 
tested,  and  maintained  and  what  tools  will  be 
needed  to  accomplish  these  tasks.  For  systems 
developed  for  large-scale  computers,  a  host  of 
compilers,  data  base  managers,  editors,  display 
Interface  packages,  flow  chart  packages,  plot 
packages,  utility  routines,  and  test  data 
generation  tools  are  generally  available  [8:221. 

The  benefits  of  using  software  development  tools  are 

numerous  and  only  limited  by  the  number  of  tools  available. 

Rook  contends  that  software  development  tools  can 

assist  in  increasing  productivity  and  visibility  of 
work  achieved,  provide  source  of  data  for  future 
proposal  preparation,  estimation  and  project 
planning,  and  maintain  continuity  between  projects 
[37:71 . 

The  conclusion  is  that,  when  software  development  tools  are 
available,  they  should  be  used  to  decrease  development 
schedule. 

Identification  of  Resource  Requirements.  Identifying, 
as  precisely  as  possible,  the  resources  required  to  complete 
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the  software  development  program,  many  experts  believe,  is 
vital  to  accurately  predicting  the  software  development 
schedule.  Brooks  relates  a  story  of  one  Program  Manager  who 
found  schedules  consistently  taking  twice  as  long  as 
estimated.  After  Investigation,  "the  estimation  error  could 
be  entirely  accounted  for  by  the  fact  that  his  teams  were 
only  realizing  50  percent  of  the  working  week  as  actual 
programming  and  debugging  time  (7:89).  This  was  due 
primarily  to  the  unavailability  of  resources  because  of 
"machine  downtime,  higher-priority  short,  unrelated  jobs, 
meetings,  paperwork,  company  business  ..."  (7:89). 
Resources  were  not  properly  identified  because  "an 
unrealistic  assumption  about  the  number  of  technical  work 
hours  per  man-year"  was  made  (7:90). 

Pressman  also  notes  that  determining  the  availability  of 
the  target  machine  (machine  on  which  the  software  will  be 
used)  is  important  when  estimating  schedule  (29:85).  Extra 
time  should  be  taken  so  that  all  resources  that  must  be  used 
during  the  development  program  can  be  identified  and  their 
availability  determined  in  order  that  program  schedule  can 
more  accurately  be  estimated. 

Other  Factors.  There  are  other  factors  that  while  not 
elaborated  on  in  detail  by  experts,  they  are  often  mentioned. 
These  factors  are  listed  below. 

1)  Use  of  a  Higher  Order  Language  vs.  assembly  language 
(47:159) 

2)  Interface  Requirements  (15:290) 
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3)  Reliability  Requirenents  (8:21) 

4)  Type  o£  8o£t%«re  to  be  developed  (47:159) 

5)  Type  o£  contract  £or  the  developaent  program 
(47:159). 

6)  Recurring  neglect  £or  8o£tware  maintenance 
(38:52) . 

Conclualon.  A£ter  a  review  o£  the  current  literature  on 
8o£tware  development,  %rritten  by  notable  experta  in  the 
£ield,  tiMlve  £actor8  have  been  ldenti£ied  aa  conalatently 
being  mentioned  by  experta  aa  a££ecting  ao£tware  development 
achedulea.  Theae  £actor8  are  preaented  in  Table  3  below. 
Other  £actora  have  alao  been  mentioned  by  experta,  but  not  aa 
£requently,  or  in  aa  much  detail,  aa  theae  twelve. 


Table  3 

Pactora  Conalatently  ldentl£ied  By  Bxperta 
Aa  A££ecting  Schedule 

1.  Iilnea  o£  code 

2.  Requireamnta  definition 

3.  Complexity 

4.  Work  Breakdo%m  Structure 

5.  Amount  of  prior  planning  perforawd 

6.  Software  development  atandarda 

7.  Uae  of  management  principlea 

8.  Software  programemr  ability 

9.  Data  baae  requlreawnta 

10.  Alloemnce  for  teat 

11.  Uae  of  aoftware  development  toola 

12.  Identification  of  reaource  requirementa 


Question  Two 

What  ia  the  importance  of  achedule  rlak  to  a  aoftware 
development  program? 

a)  To  what  degree  do  program  manager a  conaider 
achedule  riak  %fhen  eatimatlng  the  coat  of  a 
aoftware  development  program? 
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The  first  part  of  this  question  was  answered  by  a  review 
of  current  literature.  The  sub-part  to  this  question  was 
determined  after  interviewing  program  managers  and  engineers 
from  the  various  product  divisions  of  AFSC  who  have  had 
experience  in  software  development  and  experts  in  the  field 
of  software  development  in  private  industry. 

Review  of  Literature.  To  determine  the  importance  of 
schedule  risk  on  a  software  development  program,  one  can 
examine  what  program  managers  and  engineers  who  have  managed 
or  who  are  currently  managing  software  development  programs 
have  said  about  schedule  risk  and  how  it  has  affected  their 
programs.  As  seen  earlier  in  the  review  of  literature 
supplied  in  answer  to  Investigative  Question  One,  software 
development  program  managers/engineers  and  experts  have  shown 
a  keen  Interest  in  schedule  from  their  readiness  to  discuss 
the  factors  that  affect  schedule  in  their  writings.  Because 
many  of  these  people  are  very  concerned  with  the  factors*  that 
affect  schedule  in  their  development  programs,  it  would  also 
seem  they  would  be  concerned  about  the  schedule  risk  (or  the 
probability  of  the  program  not  being  completed  on  time) 
associated  with  their  program. 

For  a  software  development  program  manager,  the  reasons 
for  placing  importance  on  schedule  risk  become  intuitively 
obvious.  The  first  and  far  most  important  reason  is 
allocation  of  resources.  When  the  schedule  of  a  software 
development  program  is  set,  resources  are  allocated  to  the 
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fulfillment  of  this  schedule,  if  the  schedule  slips,  more 
time  (an  allocated  resource)  Is  required  and  subsequently 
more  resources  that  were  not  planned  on  being  allocated  to 
the  program  must  be  allocated.  These  later  allocated 
resources  are  usually  more  costly  because  of  the  fact  they 
were  not  allocated  for  In  the  first  place. 

Bruce  and  Pederson  emphasize  the  Importance  of  schedule 
risk  when  they  contend  one  of  the  major  problems  In 
estimating  software  development  costs  Is  the  "high  level  of 
risk  and  uncertainty  In  the  estimate"  (8:16).  They  believe 
that  schedule  risk  and  uncertainty  are  basically 
attributable  to  three  factors.  These  factors  are:  1) 
requirements  are  subject  to  change;  2)  Innovation  may  be 
required  during  the  development  process;  3)  risks  are 
Inherent  In  the  software  development  process  because  errors, 
which  are  Inevitable,  may  cause  iteration  over  prior 
activities  (8:16). 

Rook  has  slightly  different  Ideas  on  the  factors  that 
comprise  schedule  risk.  He  says  the  sources  of  risk  can  be 
placed  In  three  main  categories  (37:8).  These  categories 

I 

are:  1)  perturbations,  which  he  defines  as  requirements 
change,  and  detection  of  problems,  errors  and  failures;  2} 
personnel,  defined  as  the  wrong  people  available,  and  too 
many/too  few  people  available;  3)  project  environment,  which 
comprises  an  undefined  methodology,  unknown  quality,  errors 
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detected  late,  and  Inadequate  control,  technical  skill, 

support  and  visibility  (37:8). 

Donald  J.  Reifer,  author  of  **The  Software  Engineering 

Checklist,"  also  relays  the  Importance  of  schedule  in  his 

writing.  In  his  article,  he  lists  schedule  risk  as  one  of 

the  top  items  management  should  place  on  their  software 

engineering  checklists  (35:127).  He  says  the  manager  should 

ask,  "Is  the  software  development  schedule  reasonable  and  has 

adequate  time  been  allocated  for  test?"  (35:127).  He 

believes  the  typical  software  development  schedule  does  not 

allocate  sufficient  time  for  test  and  subsequently  increases 

the  program's  schedule  risk  (35:127). 

Thomas  H.  Bruggere,  author  of  "Software  Engineering: 

Management,  Personnel  and  Methodology,"  gives  his  perspective 

on  the  importance  of  examining  schedule  risk.  He  says  that 

schedule  risk  should  be  examined  throughout  every  phase  of 

the  software  development  life  cycle. 

Problems  that  are  discovered  during  one  phase  of 
the  project  must  be  fed  back  to  an  earlier  phase  to 
be  fixed.  Obviously,  the  later  a  problem  is 
discovered  and  the  farther  back  it  must  go  to  be 
solved,  the  more  expensive  the  solution  [9:251. 

He  also  emphasizes  that  because  schedule  risk  is  an  Important 

area  for  examination,  program  managers  should  utilize  the 

review  process  to  ensure  design  goals  and  specifications  are 

being  met  (9:26).  He  also  believes  that  program  managers 

should  closely  track  schedules  to  ensure  the  project  will  be 

completed  within  allowable  time  limits  (9:26). 
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Dzlscoll  states  there  are  two  areas  where  the  program 
Banager  can  protect  the  prograa  froM  cost  and  schedule 
iapacts  of  changes  and  thus  reducing  schedule  risk.  These 
areas  are  planning  and  configuration  nanageaent  (19:47). 
Driscoll  explains  substantive,  early  planning  can  work  to 
reduce  schedule  risk  by  "providing  schedule  flexibility,  and 
adequate  coaputer  size"  (19:47). 

The  second  reason  those  involved  with  soft%#are 
developaent  prograas  are  concerned  %nth  schedule  risk  is 
political.  It  becoaes  a  great  eabarrassaent  to  all  those 
involved  when  a  project  slips. its  schedule.  Often  the 
success  of  a  project  is  not  judged  by  its  total  quality  but 
by  %rhether  or  not  the  project  %rais  coapleted  on  tisa  and  on 
cost. 

Dr.  Fred  Brooks  was  part  of  the  aanageaent  teaa  charged 
with  developing  the  aassive  software  for  the  IBM  360  systea. 
He  coaaented  after  the  project's  coapletlon,  "the  effort 
cannot  be  called  wholly  successful  .  .  ."  (7:78).  Reasons 
Brooks  cited  for  the  project's  failure  were  "the  product  was 
late,  it  took  aore  aeaory  than  planned"  and  the  "costs  were 
several  tiaes  the  estiaate"  (7:78).  Brooks  references 
schedule  as  the  first  factor  contributing  to  failure  in  the 
08/360  project  and  deaonstrates  the  iaportance  software 
developaent  prograa  aanagers,  and  those  for  %rhoa  the  software 
is  being  developed  place  on  schedule. 
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Howes  contends  that  one  way  to  counteract  schedule  risk 
is  to  develop  a  proven  methodology  for  conducting  the 
software  development  and  stick  with  it  (23:34).  He  believes 
schedule  risk  can  be  reduced  by  using  a  proven  methodology  to 
develop  a  WBS  (23:34).  From  this  WBS  cost  and  schedule 
estimates  can  be  made.  The  WBS  can  also  be  used  to  produce  a 
baseline  for  more  accurately  measuring  the  progress  of  the 
schedule  (23:34)  . 

Discussion  of  Interview  Results.  To  what  degree  do 
program  managers  and  engineers  consider  schedule  and  schedule 
risk?  The  answer  to  this  question  was  deduced  from  an 
examination  of  two  areas:  1)  the  degree  to  which  program 
managers/engineers  consider,  in  their  estimates,  the  factors 
that  were  determined  to  affect  schedule  risk;  2)  the 
importance  program  managers/engineers  place  on  the  factors 
they  have  determined  from  their  experience  affect  schedule 
risk.  By  examining  the  concerns  of  those  in  the  field  toward 
the  factors  that  affect  schedule,  a  deduction  can  be  made  as 
to  how  schedule  is  considered  when  developing  a  software 
development  program  estimate.  The  interviewees  were  also 
asked  other  questions  related  to  software  development  (see 
Appendices  A  &  B),  and  the  results  of  these  questions  will  be 
briefly  discussed  also. 

Twenty  people,  comprised  of  program  managers  and 
engineers  from  the  various  product  divisions  of  AFSC,  and 
persons  considered  to  be  expert  or  experienced  in  the  area  of 
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software  development  in  private  Industry  were  interviewed 
using  the  questionnaires  in  Appendices  A  &  B.  Their 
opinions  on  the  factors  affecting  schedule  and  the  importance 
placed  on  schedule  risk  were  as  varied  as  their  backgrounds. 
The  following  paragraphs  are  a  summation  of  the  interviews. 
Note:  While  conducting  these  interviews,  it  was  made  clear 
to  those  being  interviewed  that  it  was  not  the  Intention  of 
this  author  to  quote  persons'  opinions  specifically; 
however,  the  interest  here  is  to  get  a  general  consensus  on 
answers  to  the  questions  asked  in  the  interview.  Particular 
DOD  software  development  programs  are  discussed  in  a  general 
sense,  and  not  specifically  identified. 

By  far,  changes  in  requirements  was  identified  most  as 
having  the  greatest  impact  on  the  schedule  of  a  software 
development  program;  however,  reasons  given  by  respondents 
for  these  changes  in  requirements  varied. 

Those  interviewed  who  were  contracting  with  the 
government  to  develop  software  unanimously  identified  changes 
in  the  specification  of  requirements  by  the  user  as  being  the 
reason  for  requirements  changes  during  software  development. 
The  contractors  often  stated  that  in  the  early  stages  of 
software  development,  the  users  do  not  know  exactly  what  they 
want  the  software  to  perform.  In  fact,  users,  at  times,  may 
not  even  finalize  the  requirements  until  the  later  phase  of 
Critical  Design  Review  (CDR). 
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DOD  program  managers  and  engineers  also  gave  reasons  for 
requirements  changes.  Contrary  to  what  the  contractors  have 
stated,  one  respondent  Indicated  that  the  problem  was  the 
contractor  often  did  not  understand  what  the  user  wanted. 
Another  stated  that  requirements  changed  because  there  was  a 
change  in  the  standards  for  the  weapon  system  for  which  the 
software  was  being  developed.  This  appears  to  be  a  unique 
situation.  Other  reasons  for  requirements  changing  were 
changes  in  the  hardware  for  which  the  software  was  being 
developed  and  changes  in  concerns  for  the  performance  of  the 
software  (e.g.,  safety  concerns  on  an  avionics  system). 

One  representative  of  a  company  that  markets  a  software 
development  program  estimation  model  stated  that  while  he 
worked  for  the  DOD  he  was  involved  in  a  software  development 
program  that  actually  underran  its  schedule.  The 
representative  said  the  reason  the  program  did  not  overrun 
its  schedule  was  because  the  schedule  was  set  at  no  greater 
than  14  months  from  the  beginning  of  the  development  program. 
The  program  manager  of  the  program  also  stated  that  there 
would  be  no  changes  in  the  software  requirements  allowed,  in 
other  words,  no  Engineering  Change  Proposals  (ECPs).  This 
rule  was  held  throughout  the  development  process,  and  as  a 
result,  no  delays  in  schedule  occurred  as  a  result  of 
requirement  changes.  In  fact,  as  was  noted  earlier  no  delays 
occurred  at  all  and  the  program  was  completed  slightly  under 
schedule  . 
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This  example  raises  an  Important  point.  By  not  allowing 
requirements  to  change  once  a  software  development  program 
has  started,  this  example  has  shown  that  it  is  possible  to 
meet  or  underrun  an  estimated  schedule. 

The  complexity  of  the  software  being  developed  was 
another  factor  often  mentioned  by  the  respondent  as  affecting 
the  software  development  schedule.  Complexity  in  itself  is  a 
very  broad  term.  Depending  on  which  software  development 
estimation  model  is  used,  complexity  can  include  such  areas 
as  the  structure  of  the  software  (i.e.,  one  module  versus  a 
string  of  modules  that  must  be  integrated),  what  type  of 
language  is  used  (i.e.,  higher  order  versus  assembly)  and 
what  are  the  display  requirements  (i.e.,  simple  input/output 
versus  interactive).  Generally,  the  more  sophisticated  these 
variables  become,  the  more  complex  the  software.  One 
respondent  stressed  that  complexity  is  a  subjective  factor 
because  it  is  basically  one  person's  opinion.  A  programer 
experienced  in  the  more  sophisticated  software  complexity 
variables  may  not  rate  the  software  being  developed  as 
complex  as  a  programmer  with  less  experience.  The  respondent 
went  on  to  suggest  that  the  development  of  industry  standards 
in  the  area  of  determining  the  complexity  of  a  software 
program  would  be  beneficial. 

The  number  of  development  sites,  and  whether  or  not  the 
hardware  and  software  are  being  developed  concurrently,  are 
two  more  factors  mentioned  by  several  interviewees  as  greatly 
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affecting  the  schedule  of  a  software  development  program. 

One  respondent  said  that  In  a  typical  system  program  office 
(SPO)  scenario  there  will  be  a  very  general  specification  for 
the  software  and  a  very  general  specification  for  the 
hardware.  Both  the  hardware  and  software  will  be  developed 
at  different  development  sites.  Problems  that  affect 
schedule  occur  when  the  hardware  and  software  are  complete 
and  the  Integration  of  the  two  Is  attempted. 

Also  mentioned  by  the  respondents  as  affecting  schedule 
was  experience  level.  The  experience  of  the  programmer  was 
mentioned  most  often.  Examples  of  programmer  experience  are 
the  degree  to  which  the  programmer  is  familiar  with  the 
language  being  used  to  develop  the  software,  and  the 
experience  the  programmer  has  with  similarly  structured 
programs.  One  respondent  also  said  that  the  experience  the 
contractor  as  a  vdiole  has  with  the  type  of  software  being 
developed  will  greatly  affect  schedule. 

The  use  of  software  tools  was  one  more  factor  mentioned 
frequently  by  the  Interviewees  as  affecting  software 
development  schedule.  Many  agreed  that  If  good  software 
tools  are  available,  and  the  programmers  are  trained  In  their 
use,  schedule  can  be  reduced  considerably. 

Surprisingly,  the  number  of  lines  of  code  and  type  of 
code  being  developed  were  factors  not  mentioned  often  by  the 
respondents  as  affecting  schedule.  This  is  surprising 
because  of  the  heavy  dependence  of  estimation  models  on 
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predicted  lines  of  code  for  deteraining  schedule.  The 
response  nay  be  an  indication  that  estinators'  ability  to 
predict  the  nunber  of  lines  of  code  for  a  software 
developnent  program  is  inproving,  and,  subsequently,  this 
factor  has  less  affect  on  schedule.  One  respondent  did  note 
that  software  that  can  be  developed  fron  reusable  code  and 
that  requires  simple  inputs/outputs,  will  help  to  minimize 
schedule  delays. 

Another  factor  mentioned  as  affecting  schedule  was 
whether  or  not  the  contract  is  a  military  contract  because  of 
the  additional  documentation  and  formal  reviews  required  by 
military  contracts.  One  respondent  noted  that  his  firm 
continuously  experienced  schedule  slippage  because  of  the 
tioM  it  took  to  get  documents  revie%«ed  and  approved  by 
government  personnel. 

Finally,  the  factors  time  and  meomry  constraints,  the 
facilities  available,  the  database  requirements,  whether  the 
target  computer  was  also  the  developamnt  coi^uter,  and  use  of 
management  principles  were  also  briefly  mentioned  by  one  or 
more  respondents  as  factors  ^Ich  affect  schedule. 

One  aspect  that  was  noticeable  throughout  all  the 
interviews  was  that  the  interviewees  were  all  very  adamant 
about  the  factors  they  believe  affect  schedule.  The 
respondents  also  agreed  that  stronger  control  of  these 
factors  would  work  to  reduce  schedule.  This  gives  the 
indication  that  software  development  program 
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managers/engineers  and  experts  in  the  software  development 
field  place  importance  on  determining  the  factors  that  affect 
development  schedule,  and  effectively  controlling  these 
factors . 

In  addition  to  being  questioned  on  the  factors  that 
affect  schedule  in  software  development,  the  interviewees 
were  asked  other  questions  concerning  software  development  in 
order  to  obtain  a  more  rounded  picture  of  what  is  going  on  in 
the  field.  The  results  of  these  additional  questions  are 
discussed  below. 

The  interviewees  were  asked  typically,  what  type  of 
software  programs  they  had  experience  with.  The  majority  had 
experience  with  large  software  development  programs  (large 
being  greater  than  20000  lines  of  code).  The  programs  under 
development  ranged  from  management  information  systems  to 
avionics  systems  to  flight  control,  systems  and  simulators. 

The  interviewees  were  also  asked  which  software 
development  cost  models  they  were  familiar  with.  All  of  the 
respondents  were  familiar  with,  or  had  heard  of,  the  Boehm 
COCOMO  model.  Many  were  also  familiar  with  System-3  and 
Prlce-S.  Other  models  mentioned  were  the  Putnam  SLIM  model, 
the  Tecolote  Research,  Inc.  model  and  the  Ballistic  Missile 
Office  (BMO)  model. 

The  respondents  were  also  asked  whether  they  thought  a 
schedule  risk  factor,  which  would  affect  the  probability  of 
the  schedule  being  predicted  by  the  model  actually  occurring. 
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should  be  Incorporated  Into  the  cost  nodel;  or  should 
schedule  be  predicted  by  combining  iMights  of  other  factors. 
The  majority  of  the  respondents  felt  that  the  probability  of 
meeting  the  schedule  of  the  soft%#are  program  should  be 
determined  from  a  combination  of  factors,  and  not  from  a 
single  schedule  risk  factor  input  by  the  user. 

Finally  the  respondents  «#ere  asked  to  rate  the 
correlation  of  all  of  the  input  factors  used  in  the  five 
models  being  analyzed  to  schedule  (see  Appendix  A, 

Attachamnt  1  for  display  of  the  factors  and  rating  scale). 

The  results  from  this  question  %fere  tallied.  Requirements 
volatility  %nis  identified  by  the  respondents  as  the 
estimation  input  parameter  having  the  highest  correlation 
with  schedule.  Requirements  volatility  is  ah  input  parameter 
for  PRICB-S,  SoftCost>R,  SPQR/20  and  System-3  and  the  updated 
COCOMO  model.  The  top  ten  input  parameters  identified  by  the 
interviewees  as  having  the  highest  correlation  with  schedule 
are  summarized  in  Table  4. 


Table  4 

Hodel  Input  Parameters  Identified  As  Having 
The  Highest  Correlation  With  Schedule 

1.  Requirements  Volatility 

2.  Amount  of  Hardware  Under  Concurrent  Development 

3.  Bffort  Bxpended  During  Integration  and  Testing 

Phase 

4.  Development  Computer  Accessibility 

5.  Applications  Bxperience  With  Similar  Projects 

(Tie) 

5.  Deliverable  Lines  of  Source  Code  Bxcludlng 

Documents 

6.  Schedule  Constraints 
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Table  4  ( cent . ) 


Model  Input  Paraaeters  Identified  As  Having 
The  Highest  Correlation  With  Schedule 

7.  Coaplexity  of  the  Logical  Design 
(Tie) 

7.  Developaent  Coaputer  Availability 

8.  Nuaber  of  Lines  of  New  Source  Code 

9.  Level  of  Interface  With  Other  Projects  or 

Organizations 

10.  Logical  Coaplexity 


Quest ion  Throfl 

Vhat  aethods  for  deteralnlng  schedule  are  currently 
used  in  software  developaent  cost  aodels  and  have  they 
been  tested  and/or  validated? 

a)  Nhich  of  these  aethods  appear  to  be  aost  valid? 

Software  Developaent  Schedule  Theory.  Most  soft%iare 

estiaation  aodels  rely  on  the  theory  of  the  Rayleigh>Norden 

curve  as  the  basis  in  deteralnlng  prograa  schedules.  Lord 

Rayleigh,  the  British  Nobel  Laureate,  originally  described 

the  curve  that  is  now  used  to  depict  the  software  project 

life  cycle  pattern  (32:4).  Peter  Norden  of  IBM  %«s  the  first 

to  relate  the  software  project  life  cycle  to  the  Rayleigh 

curve  ( 36 : i i ) . 

Norden  showed  that  coaplex  research  and  developaent 
projects  are  coaposed  of  overlapping  phases  of  well  defined 
aanpower  build-up  and  phase-out  (27:80).  He  calls  this 
relationship  the  Life-Cycle  Manpower  Model  (27:79).  These 
cycles,  when  placed  together,  coaprise  a  larger  cycle  in  its 
entirety  (27:80).  This  bell-shaped  curve  is  called  the 
Rayleigh-Norden  curve  (see  Figure  II). 
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Figure  ll 

Raylelgh-Norden  Curve  (27:80) 
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Typically  the  Rayleigh-Morden  curve  has  a  long  tall  to 
the  right.  Reifer  states,  "The  fact  that  these  cycle  curves 
have  long  tails  explains  %diy  projects  slip.  When  the  project 
is  90\  done  in  work,  it  is  only  2/3  done  in  tiae"  (36:ii). 

Norden  says  each  cycle  can  be  described  by  the  equation; 
-at« 

y'  -  Kate  (4) 

%rhere, 

y*  «  Manpower  utilized  each  tlae  period, 

K  >  total  cumulative  manpower  utilized  by  the  end  of 
the  project, 

a  >  shape  parameter  (governing  time  to  peak  manpower), 

t  a  elapsed  time  from  start  of  cycle, 

e  a  the  base  of  the  natural  system  of  logarithms 
(27:80) . 

Norden  states  that  because  the  linking  relationships  of 
the  cycles  have  been  "encouragingly  stable"  over  a  wi/'a  range 
of  projects  for  a  number  of  years,  projections  of  manpo%#er 
and  time  requirements  can  be  made  on  the  basis  of  these 
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cycles  (27:84).  This  Is  precisely  what  nany  companies  have 
done  in  developing  their  estimation  models. 

Review  of  Models  flelacted  for  Analysis.  To  answer  this 
investigative  question,  data  %«s  run  on  five  software 
development  estimation  models  currently  in  use  by  the  DOD  and 
private  industry.  The  OKKlels  were  selected  based  on  their 
availability  for  use  with  this  research  effort. 

The  models  selected  for  discussion  and  analysis  were: 

1)  constructive  COst  Model  (COCOMO)  (4:4), 

2)  Price-S  (34:1-1), 

3)  Softcost-R  (42:1-1), 

4)  System-!  (13:1-1), 

5)  8PQR/20  (39:1). 

The  Putnam  SLIM  estimation  laodel  was  not  selected  for 
analysis  because  it  wms  not  easily  accessible  for  use. 

Pescriptlon  of  the  Data.  To  evaluate  these  models  for 
their  accuracy  in  predicting  the  schedule  of  a  software 
development  program,  data  from  an  actual  software  development 
project  was  run  on  each  of  the  models.  The  data  is  presented 
in  Appendix  C.  Bach  model  determined  what  the  schedule  for 
the  project  should  be  and  this  result  was  compared  to  the 
actual  schedule  for  the  project. 

The  data  on  the  software  development  project  was 
obtained  from  the  Software  Coat  Data  Base  which  was  compiled 


by  Paul  O.  Punch  of  the  MITRB  corporation  for  use  at  MITRB 


and  the  Blectronic  Systene  Division,  Hansco*  AFB,  HA  and  Is 
not  authorized  for  public  release  (22:v). 

The  software  Coat  Data  Base  was  coMplled  In  1987  for  two 
reasons.  First,  analysts  at  MITRB  and  BSD  have  found  that 
software  estlnatlon  Models  are  often  based  upon  data  bases 
that  nay  not  represent  BSD  prograw,  "which  are  typically 
large,  embedded,  coaplex,  highly  reliable,  real-tlae. 

Military  applications”  (22:v).  Second,  ”the  accuracies  of 
cost  estlMates  are  not  evaluated  at  the  coMpletlon  of 
projects  since  there  Is  not  budgetary  justification  to  do  so” 
(22:v).  Therefore,  little  historical  data  exists  to 
"enhance  the  personal  experiences  of  cost  analysts  and 
software  project  Managers”  (22:v). 

The  Software  Coat  Data  Base  consists  of  26  projects  and 
coaprlses  "a  total  of  110  coMputer  software  configuration 
IteMS  (CSCI)”  (22:vl).  The  sizes  of  the  projects  widely 
vary.  The  largest  project  In  the  data  set  has  %rell  over  1 
Million  lines  of  code  and  the  sMallest  has  9000  lines  of  code 
(22:A-11). 

One  average  project  was  selected  froM  this  data  base  to 
run  as  a  test  case  In  each  of  the  Models.  NuMber  of  lines  of 
code  (LOG)  %«as  the  variable  used  as  the  basis  for  deterMlnlng 
an  average  project.  Projects  at  the  high  and  low  extreae 
ends  for  LOG  were  ellMlnated  froM  the  calculation  and  LOG  for 
the  reaalnlng  projects  were  averaged  together.  The  average 
nuMber  of  LOG  for  the  data  base  was  178,663.  The  project 
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having  an  LOC  count  closest  to  this  nunber  was  project  124 
with  165,600  LOC;  therefore,  project  624  with  nodules  A,  B, 
C,  and  D  was  chosen  as  the  test  project  to  be  run  on  each  of 
the  nodels. 

Analysis  of  Results  by  Model.  The  data  fron  project  #24 
was  used  as  Input  to  each  of  the  software  developnent 
estlnatlon  nodels  selected  for  analysis.  The  following 
paragraphs  are  a  discussion  of  the  resulting  output  by  nodel. 

COCQMO.  COCOMO,  as  noted  earlier  In  Chapter  II,  Is 
a  non-proprietary  software  developnent  nodel  developed  by 
Barry  Boehn.  After  accunulatlng  the  data  for  the  data  base, 
Paul  G.  Punch,  developer  of  the  Boftwars  nata  used  the 

data  to  evaluate  COCOMO *s  ability  to  estlnate  the  type  of 
software  prograns  connonly  developed  at  BSD. 

Punch  exanlned  five  of  the  COCOMO  equations.  Aawng  the 
equations  Punch  exanlned  %mre  the  effort  and  schedule 
equations  for  the  enbedded  node  of  the  Basic  cocmo 
Internedlate  COCOMO  nodels  (22:vll).  These  equations  %>ere 
selected  for  use  In  this  research.  Recall,  the  Basic  COCOMO 
equation  for  effort  In  the  enbedded  node  Is: 

MM  -  3.6(KDSI)‘**®  (5) 

where  MM  Is  the  nunber  of  nan-nonths  required  to  develop  the 
software  product  and  KDSI  Is  the  nunber  of  thousands  of 
delivered  source  Instructions  (4:75).  The  Internedlate 
COCOMO  Nonlnal  effort  estlnatlng  equation  for  the  enbedded 
node  Is: 
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NMn.«  -  2.8(KDSI)‘**® 


(3) 


where  MMn*«.  is  the  noninal  estlnate  of  nan-months  required  to 
develop  the  software  product  (4:117).  With  the  Intermediate 
COCOMO  model,  this  nominal  estlnate  Is  adjusted  "by  applying 
effort  multipliers  determined  from  the  project's  ratings  with 
respect  to  the  other  15  cost  driver  attributes"  (4:117). 

The  Intermediate  COCOMO  adjusted  estimating  equation  Is: 

MM«,(j  -  (MM„.«i)(BAF)  (6) 

where  BAF  are  the  product  of  the  effort  adjustment  factors 
found  by  rating  the  15  cost  driver  attributes  (4:120).  To 
determine  schedule  or  duration  (TDBV),  the  result  of  this 
equation  Is  Input  back  Into  the  Basic  equation  for  schedule: 

TDBV  ■  2.5(MM)®*»*  (4:75).  (7) 

Using  the  floftware  Coat  Data  Base.  Funch  recalibrated 
the  Basic  and  Intermediate  COCOMO  estimating  equation  by 
"fixing  the  exponent  to  the  value  established  by  Boehm  and 
calculating  the  best  fit  coefficient"  (22:vl).  The 
recalibrated  Basic  COCOMO  equations  for  effort  and  schedule 
are: 

MM  -  6,5(KDSI)‘**®  (8) 

TDBV  -  3.8(NM)®-**  (9) 

The  Intermediate  COCOMO  estimating  equations  as  recalibrated 
by  Funch  are: 

MMr,...  »  3.3(KDSI)‘*»®  (10) 

MM.«J  >  3.3(KD8I)^*a»  (BAF)  (22:lx).  (11) 
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Punch  states  that  the  Boehm  schedule  equation  for  the 
embedded  mode  usually  underestimated  durations  of  projects  in 
the  BSD/MITRE  data  base  (22:vii).  Punch  recalibrated  the 
coefficient  using  12  projects  (22:vii). 

Punch  states  that  when  this  recalibrated  schedule  equation 
(sho%m  above)  \ma  used  with  the  data  in  the  Softidarc  Cost 
Data  Base,  "the  estimates  %rare  found  to  be  within  30\  of  the 
actuals  67\  of  the  time"  (22tvii).  Punch  notes  that  this 
performance  is  nearly  identical  to  that  of  the  Boehm  schedule 
equation  on  the  COCOMO  data  base  (22:vii).  Also,  Punch 
states,  "The  Boehm  COCOMO  schedule  equation  for  the  embedded 
mode  underestimated  the  durations  of  all  but  one  project  in 
the  BSD/MITRB  Data  base"  (22:viii).  He  says,  ho%iever,  "the 
recalibrated  equation  .  .  .  predicts  schedules  52%  longer 
than  the  Boehm  equation"  (22:viii). 

Similarly,  the  Boehm  Basic  model  effort  equation  for  the 
embedded  mode.  Punch  found,  tended  to  underestimate  actual 
subsystem  efforts  (22:vii).  The  coefficient  for  this 
equation  was  recalibrated  using  17  subsystems  (22:vii). 

Punch  notes  that  the  value  of  6.5  differs  significantly  from 
the  Boehm  coefficient;  however,  %fhen  the  recalibrated 
coefficient  effort  equation  was  used,  "the  estimates  were 
found  to  be  within  20%  of  the  actuals  35%  of  the  time" 
(22:vli).  Punch  states  this  performance  "exceeds  the 
performance  of  the  Boehm  Basic  equation  on  the  COCOMO  data 
base,  %rhich  had  actuals  within  20%  of  the  estimates  only  21% 
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of  the  tine”  (22:vll).  Funch  states  that  the  recalibrated 
Noninal  Interned late  nodel  equations  for  effort  in  the 
enbedded  node  (and  senidetached  node)  provided  ”narginally 
better  fits  to  the  subsysten  data”  (22:vii). 

Because  of  the  established  ability  of  the  recalibrated 
equations  to  better  estinate  BSD-type  software  developnent 
projects,  the  data  fron  project  #24  was  run  on  the 
recalibrated  equations.  The  recalibrated  Noninal 
Internediate  nodel  equations, 

-  3.3(KDSI)‘*»®  (10) 

MMadj  «  3.3(KDSI)*-^o  (BAP)  til) 

were  used  to  calculate  effort  and  the  recalibrated  Basic 
COCOMO  equation, 

TDBV  ■  3.8(MM)«»*»*  (9) 

was  used  to  calculate  schedule  or  duration  for  project  124. 

Appendix  D  gives  the  ratings  and  effort  nultlpliers 
given  to  each  of  the  COCOMO  Internediate  nodel  cost  driver 
attributes.  The  effort  nultlpliers  were  used  to  coaipute  the 
Effort  Adjustnent  Factor.  The  following  is  the  calculation 
for  schedule  using  the  Funch  recalibrated  COCOMO  Internediate 
equation  for  effort  and  the  recalibrated  Basic  COCOMO 
equation  for  schedule: 

BAF  for  Project  924  «  2.83  (see  Appendix  D), 

KOSI  for  Project  924  >  30200, 

MMr,.«.  -  3.3(30.2)‘*»®  «  250.16 
MM.«j  -  (250.16)(2.83)  «  707.96 
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TDBV  -  3.8(707.96)®-**  -  12.5  Months 
Actual  duration  for  Project  124  was  26  nonths,  twice  that  of 
the  COCOMO  Model  prediction. 

ppTcg-g.  The  project  data  was  run  in  the  PRICS-S 
MODS  2 — CSCI  with  coMponents  Model  because  the  data  for  the 
project  was  available  by  coMponents  A,  B,  C,  and  D.  This 
author  felt  the  PRICB-S  Model  %mis  not  as  user-friendly  as  the 
other  coMMercial  Models  used  in  this  analysis;  the  data  is 
More  difficult  to  input  interactively  because  the  Model  does 
not  proMpt  the  user  for  the  inputs.  The  user  can  also  input 
data  froM  a  separate  file  that  Must  be  irritten.  The  data  file 
is  not  difficult  to  %rrite,  but  it  requires  More  tiMe  than 
just  inputting  the  values  directly  into  the  Model  and  having 
the  Model  iMMediately  coMpute  the  resalt. 

The  values  input  froM  the  data  for  each  variable  in  the 
PRICB-8  Model  are  given  in  Appendix  B.  The  output  froM  the 
Model'  is  given  in  Appendix  r.  Recall,  the  actual  duration  of 
Project  t24  was  26  Months.  This  is  nuMber  accounts  for  the 
tiMe  fraMS  froM  SysteM  Design  Review  (SDR)  through  PorMal 
Qualification  Test  (FQT).  The  PRICB-S  Model  estiMates  the 
duration  froM  SysteM  Concept  (two  phases  before  SDR)  through 
Operational  Test  and  Bvaluation  (0TB)  (three  phases  after 
FQT).  For  the  corresponding  tiMe  fraMe  for  the  project  data 
(SDR  through  FQT),  PRICB-S  estiMated  the  duration  to  be  30.4 
Months . 
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goftcoat-R.  softCost-R,  as  described  earlier,  is  a 
software  developaent  prograa  estlaatlon  Model  developed  and 
Marketed  by  Relfer  Consultants,  Inc.  It  is  a  Menu  driven 
Bwdel  that  this  author  found  to  be  very  user  friendly 
priMarily  because  inputs  are  done  Interactively.  To 
initialize  an  estlMate,  8oftCost-R  asks  the  user  to  answer 
questions  in  four  different  Menus:  ManaqeMsnt  Factors  Menu, 
Staffinq  Factors  Menu,  CoMplexlty  Factors  Menu,  and 
BnvironMental  Factors  Menu  (42:ii). 

The  inputs  by  variable  used  for  Project  124  with 
SoftCost-R  are  given  in  Appendix  O.  The  output  given  for  the 
data  inputs  is  presented  in  J^pendix  H. 

goftCost'R  predicted  the  duration  of  the  project  to  be 
21.1  Months.  Recall  again,  the  actual  duration  was  26 
Months . 

gPQR/2Q.  8PQR/20  asks  the  user  to  input  values  for 
variables  interactively  through  three  Menus.  The  first  Menu 
is  titled  8PQR/20  Input  Variables.  It  contains  general 
questions  about  the  project  such  as  what  type  of  estiMate  is 
required  (i.e.  cost  versus  schedule  or  both),  what  is  the 
MaxiMUM  staff  size  and  %rhat  is  the  average  work  week 
(39:10). 

The  second  Menu  is  titled  Bnvironawntal  Inputs.  It 
contains  questions  about  area  such  as  prograM  design,  staff 
experience  and  SMOunt  of  reusable  code  (39:18). 
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The  third  nenu  Is  titled  Coaplexity  and  Source  Code 
Input  Parameters  and  contains  questions  about  the  complexity 
of  the  new  code  being  developed  (39:21). 

There  are  two  additional  menus.  The  first.  Base  Code 
Input  Paraawters  is  used  «rhen  the  software  being  developed  is 
an  enhancement  or  Mintenance  to  existing  software  (39:26). 
The  second  is  titled  Function  Point  Pnputs  and  is  used  idien 
the  user  %fants  SPQR/20  to  predict  the  number  of  new  lines  of 
code  that  will  be  developed  (39:27). 

The  8PQR/20  model  will  estimate  development  schedule 
from  the  planning  activity  through  the  integration/test 
activity  (39:36).  The  duration  estimated  for  the 
requirements,  design,  coding  and  integration/test  activities 
was  used  in  this  analysis  because  it 'most  closely  describes 
the  time  frame  given  for  the  duration  of  Project  124.  The 
data  which  was  input  into  the  8PQR/20  model  is  given  by 
variable  in  Appendix  I.  8P(2R/20  estimated  the  duration  of 
the  project  to  be  29.21  months.  Recall  again,  the  actual 
duration  for  Project  124  was  26  months.  The  summary  output 
from  the  awdel  is  shown  in  Appendix  J. 

System- 3.  8y8tem-3  is  also  a  fairly  user  friendly 
model  that  is  also  menu  driven.  One  of  its  menu  features 
allows  the  user  to  break  do%m  a  large  project  being  estlamted 
by  groups  within  the  project,  by  tasks  within  the  group  and 
by  eleawnts  within  the  tasks.  For  this  analysis,  the  data 
was  run  at  the  project  level  because  the  specific  information 
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required  to  run  Modules  K,  B,  C,  and  D  at  the  group  level  vms 
not  available. 

Systen-S  also  has  eight  Menu  screens  for  Input  of 
variable  data.  These  screens  are  titled  Developer 
Technology,  BnvlronMntal-Co^^uter,  Bnvlronaental-Product, 
Bnvlronaental-Support,  Size  a  CoMplexlty  SussMry,  DevelopMent 
Constraints,  Reuse-Rebulld  la^ct,  and  Financial  Factors 
(13:20).  The  values  input  at  each  of  these  nenu  proapts  Is 
given  In  Appendix  K. 

Systea-B  calculated  a  ainlaua  tlae  estlaate  for 
developaent  tlae  and  Integration  tlae  as  24.09  aonths. 
Systea-3  also  calculated  requlreaents  tlae,  ho%wver,  this 
tlae  ms  not  Included  because  it  ms  not  included  In  the 
actual  duration  tlae  of  26  aonths  for  Project  124.  The 
output  given  for  the  Project  124  data  Is  given  In  Appendix 
L. 

flu— arv  of  Results.  The  schedule  tlaes  given  by  the 
five  aodels  analyzed  for  the  Project  124  data  is  suaaarlzed 
In  Table  5  below.  8y8tea-3  aost  closely  estlaated  the 
duration  for  Project  124  with  a  difference  of  1.31  aonths 
below  the  actual  duration.  The  aodel  that  predicted  farthest 
froa  the  actual  ms  the  BSD  recalibrated  COCOMO  aodel  with  a 
difference  of  13.5  aonths  under  the  actual  schedule.  All  of 
the  other  four  aodels  estlaated  duration  within  five  aonths 
of  the  actual  schedule. 
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TABLE  5 


Estlnated  Project  Duration  by  Model  (in  months) 


Months 

J^tual 

Difference 

ESD  Recalibrated 
COCOMO 

12.50 

26 

13.50 

( under ) 

PRICE-S  (MODE  2) 

30.40 

26 

4.40 

(over ) 

SoftCost-R 

21.10 

26 

4.90 

( under ) 

SPQR/20 

29.21 

26 

3.21 

(over ) 

System- 3 

24.69 

26 

1.31 

( under ) 

QttOation  PQUI 

In  cost  models,  ^at  is  the  significance  of  schedule 

risk? 

a)  Is  schedule  risk  an  independent  variable  or 
does  its  significance  depend  on  the  value  of 
other  independent  variables  in  the  cost  models 
such  as  size  of  the  program,  number  of 
programmers  required,  or  level  of  software 
sophistication  required? 

The  models  selected  for  this  analysis  were  the  sasw  ones 
used  in  the  analysis  for  investigative  question  three.  As 
noted  earlier,  all  of  the  models,  except  the  COCOMO  model 
were  found  to  contain  proprietary  algorithms.  The  main 
difference  between  each  of  the  models  in  their  determination 
of  schedule  was  the  factors  the  models  used  as  inputs  to 
determine  a  program's  estimate. 

The  Boehm  COCOMO  model,  as  mentioned  earlier,  has  15 
effort  multipliers.  All  the  multipliers  influence  schedule 
to  some  degree  because  they  are  all  used  to  determine  effort 
%dilch,  in  turn,  is  used  in  the  COCOMO  schedule  equation.  By 
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far,  the  nost  significant  influence  on  schedule,  ho%#ever,  is 
lines  of  code.  The  predicted  nuadDer  of  lines  of  code  is  used 
directly  to  deternine  effort. 

After  examining  the  range  of  values  Boehm  assigns  each 
of  the  effort  multipliers  (see  Appendix  M  for  values),  it  is 
evident  that  those  with  the  possibility  of  most  significantly 
influencing  effort  (and  schedule)  in  descending  order  of 
influence  are:  execution  time  constraint,  product 
complexity,  main  storage  constraint,  analyst  capability, 
programBMr  capability  and  required  software  reliability.  The 
other  nine  effort  multipliers  have  a  relatively  lower 
influence  on  effort. 

PRICB-8  uses  a  series  of  equations  to  determine  the 
schedule  of  a  software  development  program.  PRXC»>8  computes 
schedules  for  design  (preliminary  and  detail),  code  (unit  and 
CSC),  and  test  (CSCI).  Most  of  actual  values  used  by  these 
equations  are  proprietary,  but  the  factors  used  to  compute 
the  equations  are  not.  The  schedule  equations  for  PRICB-S 
rely  heavily  on  these  factors: 

1)  NBVD  *■  represents  amount  of  code  requiring  new 

design  (28). 

2)  NBWC  -  represents  amount  of  new  code  required 

(28). 

3)  SLOC  -  source  lines  of  code  required 

(34:11-A10) . 

4)  APPL  -  the  user  defined  application  value 

that  describes  the  application  mix 

of  the  softt«are  (34:11-A12). 


88 


5)  UTIL  -  the  factor  describing  the  fraction  of 

available  hardware  cycle  tiae  or  total 
aeMory  capacity  used  (34:11-A4). 

6)  CPLXl  -  the  factor  t^ich  provides  a  quantitative 

description  of  the  relative  effort  of 
complicating  factors  on  the  software 
developsMnt  task.  Complicating  factors 
are  product  familiarity,  personnel 
skills,  software  tools,  and  any  unusual 
factors  present  in  the  development 
environment  that  affect  the  development 
schedule  (34:11-A8). 

7)  PROPAC  -  an  empirically  derived  paraiseter  which 

Includes  such  items  as  skill  levels, 
experience,  productivity,  and 
efficiency  (34:11-A10). 

8)  PLTFM  -  a  value  ranging  from  0.6  to  2.5  %diich  is 

a  measure  of  the  customer's  requirements 
for  portability,  reliability, 
structuring,  testing  and  documentation 
required  for  acceptable  contract 
performance  ( 34 : 11**A2 ) . 

9)  ZTICH  a  technology  Improvesmnt  factor 

(28). 


The  equation  for  schedule  in  the  PRICB-S  model  is 

0  r 

Schedule  -  «  •  P  •  «T  •  CPLXl 


where. 


«,  0,  r  «  proprietary  values 


and. 


«  0 

P  «  K  •  PROPAC  •  (PLTPM/K)  • 


r 

ZTBCH 


0 

«T  «  SLOCm  •  8  •  UTIL 


where. 


(12) 


K  ■  proprietary  value 
SLOCm  «  SLOC  *  APPL 
S  ■  required  effort  (28). 
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While  PRICE'S  uses  all  these  values  Mentioned  in  the 
schedule  equation,  it  appears  that  the  key  value  that  is 
input  first,  and  the  basis  for  the  rest  of  the  equations,  is 
SLOG. 

It  is  not  clear  what  types  of  equations  the  renaining 
three  Models  analysed;  SoftCost'R,  SPQR/20,  and  SysteM-3; 
use  to  derive  schedule  because  no  indication  is  given  in 
their  docuMentation.  However,  after  running  the  Models,  it 
is  clearly  evident  to  this  author  that  these  Models  also  rely 
heavily  on  the  predicted  nuMber  of  lines  of  code  to  predict 
schedule.  One  Model,  8PQR/20  will  predict  lines  of  code  for 
the  user  with  a  technique  discussed  earlier  called  Function 
Points. 

Th'e  other  inputs  to  these  Models  (that  also  affect 
schedule  to  some  degree  that  is  proprietary)  are  basically  a 
variation  of  the  15  effort  Multipliers  developed  by  BoehM  for 
the  COCOMO  Model.  One  Might  assuMe  that  the  factors ■ known  to 
way  heavily  on  schedule  for  the  COCOHO  equation,  such  as 
product  coMplexity,  analyst  capability,  and  required  software 
reliability,  would  also  weigh  heavily  in  these  proprietary 
Models . 

In  conclusion,  it  is  evident  froM  exaMination  of  the 
equations  used  in  COCOHO  and  PRICB-S  that  schedule  and 
schedule  risk  are  significant  deterMinants  in  calculating 
these  Model's  estiMates.  Schedule  risk  is  a  function  of  the 
values  of  Many  variables  as  can  be  seen  by  the  variety  of 
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variables  used  as  inputs  into  all  five  of  these  models.  For 
some  models  schedule  is  taken  into  direct  consideration  when 
the  models  ask  if  there  are  any  schedule  constraints 
involved;  however,  none  of  the  models  analyzed  here  asks  for 
a  single  schedule  risk  input.  All  appear  to  derive  schedule 
risk  from  a  combination  of  the  other  variables.  The  heaviest 
%#eighted  of  these  variables  in  determining  schedule  is  number 
of  lines  of  code. 

Queatlon  Five 

Can  any  of  these  methods  be  combined  or  incorporated 
into  a  new  and  more  accurate  method  for  accounting  for 
schedule  risk  in  cost  awdels? 

To  address  this  question,  a  clarification  of  the  term 
methods  must  be  amde.  Methods  in  this  question  means  the 
processes  through  which  the  five  models  previously  analyzed 
predict  schedule.  As  noted  earlier,  this  process  in  all  the 
models  except  COCOHO  is  proprietary.  Therefore,  it  is  really 
uncertain  to  someone  not  having  knowledge  of  all  the 
proprietary  algorithms  whether  or  not  any  of  the  methods  can 
be  combined  or  Incorporated  into  a  new  more  accurate  model. 

Hovrever,  one  can  observe  from  using  the  models  on  a 
test  case,  that  they  all  basically  require  the  same  Inputs  in 
various  forms.  Therefore,  because  these  inputs  are  the  crux 
of  the  equations  used  to  predict  schedule,  more  eii4>hasis 
should  be  placed  instead  on  more  accurately  determining  the 
values  for  these  variables.  That  will  happen  when  (and  if) 
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standards  are  developed  for  Making  the  estisMtlon  of  these 
variables  as  objective  as  possible. 


For  Instance,  cosq^lexlty  of  the  prograa  Is  a  relatively 
subjective  Input  variable  that  can  vary  depending  on  the 
experience  of  the  prograasMr  Baking  the  est last Ion  and  not 
actually  perforsilng  the  work.  The  prograsner  %#orklng  on  the 
prograa  may  have  a  different  value  for  the  cosiplexlty  of  the 
prograsi.  In  the  sasa  light.  Methods  for  accurately 
estlMatlng  another  crucial  Input  variable,  lines  of  code, 
should  be  Investigated  as  %mll. 

In  conclusion.  It  Is  uncertain  because  of  the 
proprietary  nature  of  these  equations  whether  they  can  be 
coMblned  or  Incorporated  to  sake  a  More  accurate  BK>del; 
ho%aver,  it  Is  certain  that  Methods  for  More  accurately 
estlMatlng  the  variables  Input  Into  these  Models  should  be 
developed. 
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V.  Concluaiona  and  Recoiaandatlons 

Cone lua Iona 

The  schedule  of  a  softimre  developMnt  program  can  be 
affected  by  a  large  array  of  varying  factors.  This  research/ 
ho%fever/  has  identified  twelve  of  these  factors  as  having  the 
greatest  impact  on  the  schedule  of  a  software  development 
program.  Determination  of  these  factors  tias  made  through 
extensive  revietra  of  literature  written  by  experts  in  the 
8oft%fare  development  field.  The  twelve  factors  identified 
%rere:  lines  of  code,  requirements  definition,  complexity, 
work  breakdown  structure,  amount  of  prior  planning  performed, 
soft%Mire  development  standards,  use  of  management  principles, 
allowance  for  test,  use  of  software  development  tools  and 
identification  of  resource  requirements. 

These  factors  were  confirmed  through  Interviews  with  000 
program  managers/engineers  and  commercial  software 
development  estimation  experts  as  heavily  influencing  the 
schedule  of  software  development  programs.  The  factor  most 
often  mentioned  in  these  interviews  as  causing  delays  in 
schedule  was  requirements  definition.  The  interviewees 
agreed  that  the  requirements  of  the  software  development 
program  are  either  inadequately  specified  at  the  beginning  of 
development  or  they  are  not  firm  requirements  and 
subsequently  changes  causing  delays  are  made  during 
development . 
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Because  changes  in  requlreMents  definition  was 
identified  HK>st  often  as  being  the  priaary  cause  for  software 
developaent  schedule  slippage,  software  developaent  prograa 
Managers  should  investigate  %iays  to  More  accurately  deteraine 
the  requireaents  of  a  prograa. 

Five  software  developaent  Models  were  analyzed  using  a 
data  base  developed  by  Blectronic  Systea  Division  of  Air 
Force  Systeas  Coaaand.  The  five  Models  chosen  were  an  SSD 
recalibrated  COCOHO  aodel,  PRICB-8,  SoftCost-R,  SPQR/20  and 
Sy8tea-3.  Using  data  froa  one  BSD  software  developsant 
project  as  a  case  study,  8ystea-3  %rais  sho%m  to  predict  its 
schedule  with  the  aost  accuracy  by  predicting  the  schedule 
within  1.31  Months  of  the  actual.  The  next  aost  accurate  for 
this  case  was  8PQR/20,  then  PRlCB-8,  and  then  8oftCost>R. 

The  worst  predictor  of  the  case's  schedule  was  the  BSD 
recalibrated  COCOHO  aodel.  Its  predtctlon  was  13.5  aonths 
under  th<*  actual.-  In  suaaary,  it  is  evident  froa  this  case 
that  all  of  the  aodels  analyzed  except  the  BSD  recalibrated 
COCOHO  aodel  did  very  well  at  predicting  the  project's  actual 
schedule.  These  four  Models'  predictions  were  all  within 
five  aonths  of  the  actual  schedule. 

An  exaaination  of  the  equations  used  in  the  COCOHO  aodel 
and  the  PRlCB-8  aodel  has  revealed  that  these  aodels  use  a 
coablnation  of  variables  to  predict  schedule.  Soae  are  aore 
heavily  %reighted  than  others.  It  can  be  assuaed  that  is  also 
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the  case  with  other  three  models  analyzed  whose  equations 
used  to  determine  schedule  are  proprietary. 

To  develop  a  more  accurate  model  for  predicting  the 
schedule  of  a  software  development  program,  emphasis  should 
be  placed  not  on  developing  new  models  but  on  developing 
better  methods  for  accurately  predicting  the  variables  which 
are  Input  Into  these  models. 

p»>f?niMi>^nda  1 1  ons 

Further  research  In  the  area  of  schedule  determination 
for  software  development  programs  Is  needed  In  order  to  help 
estimators  more  accurately  estimate  these  schedules.  The 
following  paragraphs  are  suggestions  for  areas  of  continued 
research. 

Twelve  factors  were  Identified  as  heavily  affecting  the 
development  schedules  of  software.  The  number  one  cause  of 
delays  In  schedule  Identified  appears  to  be  Inadequate 
definition  of  requirements.  Further  research  should  be  done 
to  determine  what  are  the  reasons  for  changes  In  requirements 
definition  and  how  can  changes  In  requirements  definition  be 
reduced . 

Because  of  time  limitations,  only  one  project.  Project 
124  data  was  Input  Into  each  of  the  five  software  estimation 
models  being  analyzed  and  an  estimate  was  calculated.  It  Is 
realized  that  one  data  point  may  not  give  a  complete  picture 
of  the  accuracy  of  each  of  the  models  at  predicting  schedule. 
Therefore,  the  remaining  twency-flve  data  points  of  the  BSD 


95 


Software  Coat  Data  Baae^  developed  by  Paul  G.  Punch,  should 
also  be  Input  into  each  of  the  models  and  allow  the  models  to 
calculate  estimates  for  these  points  as  t^ell.  From  this 
data,  the  standard  deviation  of  estimates  from  actual 
schedules  should  be  calculated  for  each  model.  By  using 
twenty-six  data  points,  a  more  accurate  picture  of  each 
model's  schedule  estimation  capabilities  can  be  presented. 

There  are  several  other  software  development  estimation 
models  available  today  besides  the  five  models  analyzed  here. 
These  models  should  be  identified  and  the  data  from  the  BSD 
Software  Coat  Data  Base  should  be  used  as  a  test  case  to 
determine  the  accuracy  of  these  models  in  predicting  schedule 
also. 

Using  the  BSD  software  cost  Data  Base  for  data,  the 
twelve  factors  identified  in  this  research  as  heavily 
affecting  schedule  should  be  regressed  against  schedule  to 
determine  which  factors  are  the  most  highly  correlated  with 
schedule.  Once  this  is  determined,  a  model  can  be  developed 
from  these  factors  that  will  predict  the  schedule  for  the 
types  of  software  programs  developed  at  BSD. 
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APPENDIX  A: 


INTERVIEW  QUESTIONNAIRE 
FOR  DOD  PROGRAM  MANAGERS /ENGINEERS 


1)  What  type  or  types  of  software  development  programs 
have  you  managed  recently  (i.e.  large  or  small 
content,  what  weapon  system  was  the  software  being 
developed  for)? 

2)  Upon  completion,  did  the  software  development 
program  overrun  or  underrun  its  cost  estimate? 

a)  What  was  the  initial  estimate  for  the 
program? 

b)  What  was  the  final  cost  of  the  program? 

c)  Were  there  changes  in  the  software 
requirements  during  the  program? 
i)  If  so,  at  what  phase  and  why? 

3)  On  completion,  was  the  software  development  program 
on  schedule,  over  schedule  or  under  schedule? 

a)  What  was  the  original  schedule? 

b)  What  was  the  final  schedule? 

c)  Were  there  changes  in  the  software 
requirements? 

1)  If  so,  at  what  phase  and  why? 

4)  If  the  software  development  program  ran  over  or 
under  schedule,  in  your  opinion,  what  were  the 
factors  that  caused  this  over  or  underrun  (i.e. 
complexity  of  the  software  being  developed, 
experience  of  the  programmers,  number  of 
programmers  used,  changes  in  requirements)? 

5)  Was  a  software  development  cost  model  (or  models) 
used  to  estimate  the  cost  of  the  software 
development  program?  If  so,  what  model  was  used? 
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6)  Most  software  development  cost  models  use 
proprietary  algorithms  to  develop  program  estimates. 
In  your  opinion,  how  do  you  believe  schedule  risk 
was  Incorporated  Into  the  software  development  cost 
model  you  used  to  determine  the  cost  of  the  program 
(If  a  software  development  cost  model  was  used)?  In 
other  words,  which  factors  that  you  Input  to  the 
model  do  you  feel  contributed  most  to 
determining  the  schedule  of  the  program?  (Factors 
for  each  cost  model  being  analyzed  provided 

In  Attachment  1). 

NOTE:  Factors  are  given  at  the  end  of  this 
Appendix. 

7)  From  your  experience  with  software  development 
programs,  what  factors  do  you  consider  Important  or 
significant  when  determining  the  schedule  and/or 
schedule  risk  of  a  software  development  program? 

8)  Oo  you  think  a  schedule  risk  factor,  which  will 
affect  the  probability  of  the  schedule  being 
predicted  by  the  model  actually  occurring,  should  be 
Incorporated  Into  the  cost  model;  or  do  you  think 
schedule  should  be  predicted  by  combining  weights  of 
other  factors  such  as  program  complexity? 
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ATTACHMENT  1  (page  1  of  5) 


The  various  input  factors  listed  below  are  used  by  the 
software  development  program  estimating  models  being 
analyzed.  You  are  asked  to  rate  each  of  the  factors  in  terms 
of  to  what  extent  you  believe  they  affect  the  schedule  of  a 
software  development  program  using  the  following  scale: 


0 

1 

2 

3 

4  5 

Very 

Very 

Don '  t 

Low 

Low 

Somewhat 

High  High 

Know 

Correlation 

Correl . 

Correlated 

Correl.  Correl. 

Rating 

Factors 

^  A;  p  P 

ff  $  ^  ^  § 

Factors  Common  to  3  or  more  models 

1.  Specification  (SPEC)  « 
functional,  procedural, 
both  or  other. 

1 

X 

1 

X 

X 

2. 

Requirements  Volatility 
(RVOL) 

X 

X 

X 

X 

3. 

Main  Storage  Constraint 
(STOR) 

X 

X 

X 

X 

4. 

Computer  Turnaround  Time 
(TURN) 

X 

■ 

■ 

X 

X 

5. 

Use  of  Software  Tools  (TOOL) 

B 

B 

B 

B 

6 . 

Applications  Experience 
with  similar  projects  (AEXP) 

X 

X 

X 

X 

"'t: 

Average  Experience 

with  Techniaues  used  (TECH) 

X 

X 

X 

Programming  Language 

Experience  (LEXP) 

X 

X 

X 

T 

KH 

B 

B 

B 

B 

HI 

Software  Product 

Complexity  (CPLX) 

X 

X 

X 

X 

X 

1 

Deliverable  Lines  of  Source " 

Code  Excluding  Documents 
(DSLOC) 

■ 

X 

X 

■ 

X 

Lines  of  Source  Code 
Documentation  (DocLOC) 

X 

X 

X 

iT. 

Reusable  Code  From  Similar 
Projects 

■ 

X 

X 

e 

X 

ATTACHMENT  1  (page  2  o£  5) 


Rating  Factor 


^  S  ^  iL 

§  6  i  S  ^ 

8  ^  ^  ^ 

§  s  §  ^  ^ 


Factors  CossBon  to  2  Models 
1.  Use  of  Modern  Programming 
Practices  (MODP 


Virtual  Machine  Volatility 
(VIRT) 


3.  Execution  Time  Constraint 

(TIME)  _ 


Nu^er  of  Development  Sites 
SITES) _  _ 


5.  Virtual  Machine  Experience 
(VBXP) 


6.  Programmer  Capability  (PCAP) 

7.  Special  Display  Requirements 

(Display)  _ 


^ Effort  expended  during  the 
integration  and  testing 
base  (EFTit) 


r  Of  lines  o 
source  code 


r  of  lines  delete 
existinq  modules 


13.  Existing  LOG  ■  pre-existing 

code  orior  to  task  development 


14.  Monthly  Pay  Average 


Unique  Factors  by  Model 
System-3 

Annual  Inflation  (Financial ) 


or t -Person  Months 


Real  Time  Operation  (RTIM 


X  X 


X 


X 


X 


X 


X 


XI  X 


31 

II 


Relaxed  Schedu 


Reouirements  -  %  Developi 


8. 

Requirements  Effort 
at  Contract  Award 

Complete 

■■■■ 

X 

"§T" 

Resource  Dedication 

(RDSD) 

□ 

□ 

□ 

□ 

"x 

100 


aaaaaa 


ATTACHMENT  1  (page  3  of  5) 


Rating  Factor 


^  O'  V  ^ 

8  ^  ^  ^ 

o  a.  ^  ^ 


Unique  Factors  by  Model  (continued) 
Sy8tem-3  (continued) 


esource 


-  Requirenencs  sra 
Project  staff,  Developinent 
staff 


ystem  (virtual  Hacnine 
Complexity  (SYST) 


13.  Effective  Productivity  « 
average  lines  of  code 
completed  by  project 
erson  per  month 


SPQR/20 

1.  Estimate  Scope  (Prototype, 
Module,  System) 


man~mon 


Exempt  Personne 


veraqe 


Averaqe  Work  Year 


Project  Class  (Persona 
program  through  military 
contract 


e  Language 


Reusable  Code  Language  Level 


New  Code  Structure 


New  Code  Data  Co 


e  Language 


Language  Level 


Database  comolexit: 


Base  Code  Language 


se  Co 


Base  Code  Size 


m-m-TTnaj 
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Rating  Factor 


II 


Unique  Factors  by  Model  (continued) 

Softcost-R 

1. 

Nuaber  of  lines  changed 
other  ways  in  existing 
Bodules 

in 

2*  • 

Nuaber  of  lines  deleted 
entire  aodules 

as 

xpeccea  user  invoivenen 
in  reauire«ent8  definition 


Level  of  interface  with  other 


%  of  prograMMts  doing 
design  and  will  work 
developnent 


ype  of  technical  reviews 

i«ld 


Muaber  of  I/O  iteMS 
enerated  per  1000  lines 


veraxi  conpiexxry  o 
data  base  architecture  _ 


on^exity  of  the  logical 
desiqn  _ 


of  the  progran  in  assesubly 
language  _ 


of  total  task  will  be  eas 


Classified  Security 
environnent  for  coaE>uter 
Y/M? 


Amount  of  hardware  under 
concurrent  develoonent 


Developnent  coaputer 
accessibilit 


DevelopsMnt  coaputer 


XX  J  f  t  Uv  11.9  i 


20.  Maturity  of  systea  and 
support  soft%#are 
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Rating  Factor 


ATTACHMENT  1  (page  5  of  5) 


I  s 


\  ^ 
o?  b 


S!  P'  ^ 

m  Qm  ^ 

S  ^  CQ 


Unique  Factors  by  Model  (continued) 
SoftCost-R  (continued) 

21.  Overall  adverse  constraints 
on  proqran  desiqn 


22.  %  or  program  which  is  rea. 

tiaie  and  multi-tasicinq 


23.  Software  adapted  to  mu 
environments  (Y/M?) 


aptation  required  to 
change  from  development 
to  operational  environment 
(Y/H?) 


PRXCB^S 

INTBGI  -  the  level  of 
difficulty  of  integration 
and  testing  the  CSCIs  to 
the  system  level _  _ 


SCHEDULE  «  start  of  the 
system  software  development 
activities  and  completion 
dates  for  activities  which 
support  the  soft%rare 
development  phases 


source  language  to 
used  _ 


CPLX2  ■  quantitative 
description  of  the  relative 
effect  of  complicating 
factors  on  the  software 
development  tasic  caused  by 
hardware/software 
interactions.  Factors 
include  new  hardware 
development  and  hard%fare 
developed  in  parallel 


COCOMO 

Required  Soft%mire 
Reliability  (RELY 


Data  Base  Size  (DATA 


(SCHBD) 


APPIMDIX  B 


INTBRVZBW  QUBSTIONMAIRB 
FOR  SOFTWARE  DEVELOPMENT  EXPERTS 
(DOD  AND  COMMERCIAL) 

1)  Which  softwre  develop»ent  cost  nodsl  are  you 
fawlliar  with?  (Choose  one  or  wore) 

a)  COCOMO 

b)  Price-S 

c)  Putnaa-SLIM 

d)  So£tcost-R 

e )  Systesi-S 

f )  SPQR/20 

2)  Upon  coi^letion,  did  the  software  develops»nt 
prograai  you  have  been  involved  with,  and  used 
this  aK>del(s)  for  an  estiaate,  overrun  or 
underrun  its  cost  estisate? 

a)  What  was  the  initial  estisate  for  the 
pro^raa? 

b)  What  was  the  final  cost  for  the  program? 

c)  Were  there  changes  in  the  software 
requirements  during  the  program? 
i)  If  so,  at  what  phase  and  why? 

3)  Same  as  Questionnaire  for  DOD  program  Managers/ 
Engineers. 

4)  Same  as  Questionnaire  for  DOD  Program  Managers/ 
Engineers. 

5)  Same  as  Questionnaire  for  DOD  Program  Managers/ 
Engineers. 

6)  In  your  opinion,  how  is  schedule  risk 
incorporated  into  this  software  development  cost 
model?  In  other  words,  %rhich  factors  input  in 
the  model  contribute  more  to  determining  the 
schedule  of  the  program?  (Factors  for  each  cost 
model  being  analyzed  are  provided  in  Attachment 
1). 

NOTE:  See  Appendix  A,  ATTACHMENT  1  for 
questionnaire  attachment. 

7)  Same  as  Questionnaire  for  DOD  Program  Managers/ 
Engineers . 

8)  Same  as  Questionnaire  for  DOD  Program  Managers/ 
Engineers. 
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APPENDIX  C: 


Descx  >  Mission  Description 
1>  C3  system 


2-  radar  system 

3-  simulation 

4-  training  system 

* 

2 

2 

2 

2 

SVfncl  -  Major  Software 

Function 

• 

3.8 

3.8 

11.3 

4.9 

SVfnc2  -  Major  Software 

Function 

4.1 

15.3 

13.3 

5.3 

SVfnc3  -  Major  Software 

Function 

5.3 

17.2 

17.1 

7.1 

ICSCI  «  Number  of  CSCIs 

* 

6 

6 

6 

6 

Simul  «  CSCIs  simultaneously  * 

resident  on  Target  Conq^uter 
are  assigned  same  number. 

• 

• 

* 

* 

Specif  -  Specification 

1-  functional 

2-  procedural 

3- 1  +  2 

4-  Other  -  match  analogous 

»  1 

programs 

1 

1 

1 

Design  -  Design  Method 

1-  Top  down 

* 

1 

1 

1 

1 

2*  bottom  up 

3»  Iterative  enhancement 
4s  hardest  first 

5- 1  +  2 

6- 1  +  3 

7- 2  +  3 

Develop  -  Development  Method 

Same  as  above  *  1111 

Coding  -  Coding  Method 

1-  structured  code  *  1111 

2-  other,  pseudostructured  code 

3-  other,  by  modules 
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Project  I  24 


De0cg lotion  of  Factojra 

Testing  >  Testing  Method 
1«  top  do%m  (stubs) 

2>  bottom  up  (drivers) 

3>  specification  driven 
4«  structure  driven 
5>  Other,  input/output 
6s  other,  module  level  testing  and 
applications  software  testing 
7=  1  +  2 

8- 1+3  8 

9-  2  +  3  +  4 

10-  3  +  4  6 

11- 1+2+3+4 

V-v  -  Validation/Verification 
Method 

1-  peer  review 

2-  walls  throughs 

3-  proof 

4-  none 

5- 1+2  • 

6-  1  +  2  ♦  3 

Formal  -  Formalisms  Methods 

1-  program  design  language  * 

2-  HIPO  charts 

3-  flowcharts 

4- 1  +  2 

5- 1  +  3 

6- 2  +  3 

7-  1  +  2  +  3 

Software  Development  Tools  Used 

Tvlow  -  #  of  tools  used  from  list: 

Assembler  * 

Basic  Linker 
Basic  Monitor 
Batch  Debug  Aids 


(page  3  o£  18) 


Project  #24  (A,B,C,D)  24  A  B  C  D 

Description  of  Factora 

Tlow  s  I  of  tools  used  from  list:  *  2222 

Higher  Order  Language  Compiler 
Macro  Assembler 
Simple  overlay  linker 
Basic  Source  editor 
Language  Independent 
Monitor 

Basic  Library  Aids 
Basic  Database  Aids 

Tnom  >  I  of  tools  used  from  list:  *  2222 

Real-time  or  Time-sharing 
Operating  system 
Extended  Overlay  Linker 
Database  Management  System 
Interactive  Debug  Aids 
Simple  Programming 
Support  Library 
Interactive  Source 
Editor 

Thigh  «  I  of  tools  used  from  list:*  1  111 

Virtual  Memory 
Operating  System 
Database  Design  Aid 
Simple  Program  Design 
Language 

Performance  Measurement 
and  Analysis  Tools 
Programming  Support 
Library  with  Basic  Con¬ 
figuration  Management  Aids 
Set-use  Static  Analyzer 
Basic  Text  Editor  a  Manager 
Program  Flow  and  Test  Case 
Analyzer 
Pile  Manager 
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Tvhigh  >  I  of  tools  used  from 

list;  •  3  3  3 

Full  Progranailng  Support 
Library 

Documentation  System 
Project  Control  System 
Requirement  Specification 
Language  and  Analyzer 
Extended  Design  Tools 
Automated  Verification 
System 

Fault  Report  System 
Crosscompilers 
Instruction  Set  Simulators 
Display  Formatters 
Data  Entry  Control  Tools 
Communications  Processing 
Tools 

Conversion  Aids 
Structured  Language  Tool 

Tother  «  #  of  other  Tvhigh  tools 

used  not  listed  above.  *  000 

Tcalc  >  Calculated  Tool  Parameter 
(Ranges  from  1  «  vlow  to 

5  -  vhlgh)  •  3.26  3.26  3.26 

MODP  >  Use  of  Modern  Programming  *  .91  .91  .91 

Practices 
1.24  avlow 
1.1  >  low 
1  >  nom 
.91  -  high 
.82  «  vhlgh 

Begin  >  C(X:OMO  Project  starting 

date  (SDR)  mm.yy  9.82  9.82  9.82  9.82 

End  «  COCOMO  Project  completion 

date  (FQT)  10.84  10.84  10.84  9.84 

Duration  •  Project  duration  26  26  26  25 


0 

3.26 

.91 


9.82 

10.84 

26 
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(page  5  o£  18) 


Project  #24  (A,B,C,D)  24  A  B  CD 


Description  of  Factors 


Actual  Schedule  Milestones 


Note:  PDR  >  Preliminary  Design  Review 
SDR  a  System  Design  Review 
CDR  >  Critical  Design  Review 
Int  >  Beginning  of  Integration 
and  Testing 

FQT  s  Formal  Qualification  Test  I  of  months 


PD  >  PDR  -  SDR  (or  Contract  Award)  * 

DD  «  COR  -  PDR  * 

CUT  -  Int -CDR  * 

IT  >  FQT  (or  Complete 

CPCI  Integration) 

-  Int  • 

TOT  »  Total  Project  Time 

(PD  +  DD  +  CUT  +  IT)  * 


7  7  7 

6  6  6 

6  6  6 


6.5  6.5  5.5  6.5 


25.5  25.5  24.5  25.5 


System  Documentation 
(Pxflject  LbyrU _ 

DOCl  >  System  Engineering 

Management  Plan  (i  pages)  *  *  •  * 

DOC2  »  Computer  Program  Development  33 (total) 

Plan  (i  pages) 


DOC3  >  System  Test  Plan  (f  pages)  * 

DOC4  ■  Other  Documentation 

( I  pages )  • 

SCnum  >  Software  Change  history: 

#  of  requirements  changes 
during  software 
development  phases  ■ 

•  of  changes  approved.  * 

SCloc  >  Change  in  DSLOC  resulting 
from  the  requirements 
changes  * 

SCsm  s  Change  In  effort  resulting 
from  the  requirements 
changes  «  i  staff-months  * 


*  *  * 


*  •  • 


t  *  * 


*  *  * 


*  *  * 


* 


* 


* 


* 


* 
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Mitre  Project  Data  (page  6  of  18) 

Project  124  (A,B,C,D)  24  A  B  C  D 

Deacr lotion  of  Factors 


RVOL  «  Requirements  Volatility  Not  given 

.91  ■  low  (Essentially  none) 

1.0  >  nom  (small,  noncritlcal 
redirections) 

1.19  >  high  (Occasional  moderate 
redirection) 

1.38  «  vhigh  (Frequent  moderate 

or  occasional  Mjor) 

1.62  a  ehigh  (Frequent  major 
redirection) 

PeYelopBBnt  and  Target  coaputer  Data 


VIRT  -  Virtual  Machine  Volatility 
.87  >  vlow  (no  Mjor  changes; 

minor  change  every  12 
months ) 

.87  «  low  (maj.  changes  every  .87 
12  mos;  minor  changes 
every  month) 

1.0  «  nom  (maj.  changes 

every  6  mos  minor 
changes  every  2  %feeks) 
1.15  «  high  (maj  changes  every 

2  mos;  minor  changes 
every  week) 

1.3  «  vhigh  (maj  changes  every 

2  weeks;  minor  changes 
every  2  days) 


.87  .87  .87  .87 


STOR  >  Main  Storage  Constraint 

(CPU  Memory  Percent  Utilization) 

Maximum  %  of  processing  time  used 
by  any  group  of  CSCIs  executing 
concurrently  on  single  machine. 

1.0  ■  nom  (<>50%) 

1.06  >  high  (51-70%) 

1.21  «  vhigh  (71-85%) 

1.56  >  extra  hi  (86-95%)  1.56  1.56  1.56  1.56  1.56 
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Mitre  Project  Data  (page  7  of  18) 

Project  124  (A,B,C,D)  24  A  B  C  D 

Description  of  Factors 

TIME  ■  Execution  Time  Constraint 
(Execution  Time  Percent 
Utilization) 

Maximum  %  of  processing 
time  used  by  any  group  of 
CSCIs  executing  concurrently 
on  single  machine 
1.00  >  nom  (<>50%) 

1.11  «  high  (51-70%) 

1.30  -  vhlgh  (71-85%)  1.3  1.3  1.3  1.3  1.3 

1.66  -  ehlgh  (86-95%) 

MemCE  »  CPU  Memory  Constraint 
Evaluation 
Measures  required  to 
satisfy  the  reserve 
memory  requirement 

1  «  no  mem  economy  measures 

req'd 

2  ■  some  overlay  use  or 

segmentation  req'd 

3  •  extensive  overlay 

and/or  segmentation 

req'd  3  3333 

4  >  complex  memory 

management  economy 
measures  req'd 

TlmCE  s  CPU  Time  Constraints  Evaluation 
Percentage  of  software 
that  requires  special 
coding  effort  to  enhance 
timing  performance 

1  >  no  software  is  cpu 

time  constrained 

2  «  <25%  of  source  code 

is  time  constrained  1  1111 

3  a  25-50%  of  source  code 

is  time  constrained 

4  <■  50-75%  of  source  code 

is  time  constrained 

5  «  >75%  of  source  code 

is  time  constrained 


111 


(page  8  o£  18) 


Project  124  (A,B,C,D)  24  A  B  C  D 

DeacrlPtlon  of  Factora 


TURN  >  Conputer  Turnaround  Tl«e 

.87  ■  low  (Interactive) 

1.00  «  non  (ART<4hr)  1  111 

1.07  -  high  (ART<12hr) 

1.15  -  vhlgh  (ART>12hr) 

ART  >  Avg  Reaponae  Tine  fron  job 

aubnlaalon  until  reaulta 
are  back  In  developer 'a 
handa  ( " logo- to-hardcopy " ) 


Percentage  of  Sourea  Inatructlona  Developed  fav  Bach  Acceaa 


1 


Batch  «  Batch  >  %  of  total  DSI  0 


0  0  0  0 


DedP  >  Dedicated  Proceaaor  100 

«  %  of  total  DSI 
TBhp  «  Teat  Bed  with  High 
Priority  (%  of 
total  DSI )  0 

Int  ■  Interactive 

(%  of  total  DSI)  0 

P/T  >  Avg  Munber  of  Bnglneera/ 
Progranawra  per  Ternlnal 
which  are  readily  acceaslble 
to  the  developnent  tean 
(naxlnun  •) 


100  100  IOC  100 

•0  0  0  0 
0  0  0  0 


not  given 


Sltea  «  I  of  Developnent  Sites 
and  when  there  are 
nultlple  CSCIa,  this  i 
should  Indicate  the  site 
(coded  by  f)  at  which 

each  CSCI  was  developed  1  1111 


112 


(page  9  of  18) 


TOOL  •  Use  of  Software  Tools 

1.24  >  vlow  (Basic 

microprocessor 

tools) 

1.10  >  low  (Basic 

minicomputer 

tools) 

1.00  «  nom  (strong 
minicomputer 
or  basic 
maxicomputer 
tools) 

.91  •  high  (strong 

maxi computer 

tools)  .91  .91  .91  .91  .91 

.83  ■  vhigh  (advanced 

maxicomputer 
tools) 


ABXP  «  Application  Experience 

with  Techniques  Used  1.13  1.29  1.29  1.29  1.29 

1.29  «  vlow  (<4mos) 

1.13  ■  low  (5  mo  -  3  yrs) 

1.00  «  nom  (3  yrs  -  6  yrs) 

.91  -  high  (6  yrs  -  12  yrs) 

.82  ■  vhigh  (>»12  yrs) 


Tech  ■  Avg  Experience  with 

Techniques  Used  *  1133 

1  •  1-4  mos.  avg.  experience 

2  •  4sk>s  -  1  yr 

3  ■  1  -  3  yrs 

4  ■  3  -  5  yrs 

5  ■  >■  6  yrs 


LEXP  >  Programming  Language 

Experience  1.14  1.14  1.14  1.14  1.14 

1.14  ■  vlow  (<«  1  mo.  avg.  exp.) 

1.07  «  low  (4  mos  -  1  yr) 

1.00  «  nom  (1  yr.  -  3  yr) 

.95  -  high  (>■  3  yrs) 
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Project  124  (A,B,C,0) 


Project  Data  (page  10  of  18) 

lA _ _ B _ Q _ D. 


Description  of  Factors 

VBXP  «  Virtual  Hachlne 

Experience  1.21  1.21  1.21  1.21  1.21 

(developnent  and 

target  computer 

hardtmre,  operating 

systeas  and  architecture) 

1.21  >  vlow  (<»  1  ao.  avg.  exp.) 

1.10  ■  low  (4  aos.  -  1  yr.) 

1.00  >  noa  (1  yr.  -  3  yrs) 

.90  «  high  (>■  3  yrs) 

SS/T  ■  Average  Experience  with 
Support  Software/Tools 

1  ■  <  1  ao. 

2  ■  1  -  4  aos. 

3  «  4  aos.  -  1  yr. 

4  ■  1  yr.  -  3  yrs. 

5*3  yrs.  -  6  yrs. 

PCAP  •  Prograsaar  capability 
Avg.  personnel  quality 
with  respect  to  overall 
industry  population. 

Based  on  the  progzaaalng 
teaa's  aptitude  for 
pr  ogr aaai ng/des i gn i ng 
software,  efficiency 
and  thoroughness,  and 
ability  to  coaaunicate 
and  cooperate. 

1.42  >  vlow  (15th  percentile) 

1.17  «  low  (>35th  percentile) 

1.00  >  noa  (>55th  percentile) 

0.86  >  high  (>75th  percentile) 

0.70  a  vhigh  (>90th  percentile) 

ACAP  a  Analyst  Capability  1  1.19  1  .86  .86 

Avg.  personnel  quality 
as  described  above 

1.46  a  vlow  (15th  percentile) 

1.19  a  low  (>35th  percentile) 

1.00  a  noa  (>55th  percentile) 

0.86  a  high  (>75th  percentile) 

0.71  a  vhigh  (>90th  percentile) 


1  14  4 


1  1.17  1  .86  .86 
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Project  124  (A,B,C,D)  24  A  B  C  D 

Deacrlptlon  of  Pactora 

MpAvail  «  %;  Degree  to  which  Manpower 
loading  levels  are 
constrained  by  personnel 
availability  or  budget 
1 ini tat ions  (100%  ■  no 

nanloading  constraints)  100  100  100  100  100 

PkMload  «  Peak  Software  Developnent 
Team  Hanloading  over  the 

course  of  the  project  (i)  33  15  2  6  11 

RBLY  «  Required  Software 
Reliability 
.75  ■  vlow 
.68  >  low 
1.00  >  non 
1.15  -  high 
1.40  •  vhigh 

CPLX  «  Software  Product 
Complexity 
.70  ■  vlow 
.85  «  low 
1.0  >  non 
1.15  -  high 
1.30  «  vhigh 
1.65  >  ehigh 

SpecQ  ■  Quality  of  Specification  *  0  101 

0  «  very  precise 

1  «  precise 

2  «  imprecise 

DSLOC  >  Deliverable  Lines 
of  Source  Code 
Excluding 

Documentation  185600  87700  18300  29500  50100 

DocLOC  *  Lines  of  Source  Code 

Documentation  180400  108200  20000  16000  36200 


1.15  1.15  1.15  1.15  .88 


1^15  1.3  1.15  1.15  .85 
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Project  #24  (A,B,C,D) 
Description  of  Factors 


21. 


_a. 


.94 


.94 


DATA  =  Data  Base  Size 

.94  =  low  (D/P<10) 

1.00  =  nom  (10<D/P<100) 

1.08  =  high  (100<D/P<1000) 

1.16  =  vhigh  (D/P>=1000) 

D/P  »  Data  Base  Size  in  Bvtes  or  Characters 

LOG 


.94 


94  .94 


DSR  -  Data  Storage  and  Retrieval  (%) 

1  MM 

* 

0 

5 

10 

4 

OLC  =  On-Line  Conununi  cat  ions  (%} 

* 

10 

5 

0 

11 

RTC&C  »  Real-time  Command  and 

Control  (%) 

* 

0 

0 

0 

0 

IntOp  s  Interactive  Operations 

* 

35 

0 

0 

12 

MathOp  3  Mathematica>l  Operations  (%) 

* 

55 

90 

10 

31 

String  -  String  Manipualtion  (%) 

0 

0 

80 

42 

OS  -  Operating  Systems  (%) 

* 

0 

0 

0 

0 

Operational  Response  Requirement 

as  %  of 

LOG 

RT  =  Real-Time  (%) 

* 

55 

41 

0 

16 

OL  =  On-Line  (%) 

* 

35 

0 

0 

0 

TC  =  Time-Constrained  (%) 

* 

10 

0 

0 

84 

NTC  =  Non-Time  Critical  (%) 

* 

0 

59 

100 

0 

Source  Statement  Tvoe  Mix 

as 

%  o£  LOG 

Logic  =  Logical  (%} 

* 

20 

20 

60 

32 

Commnd  =  Command  (%) 

* 

30 

10 

10 

33 

Math  »  Mathmatical  (%) 

* 

40 

60 

10 

31 

DatMan  =  Data  Manipualtion  (%) 

* 

0 

0 

10 

0 
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Project  #24  (A,B,C,D)  24  A  B  C  D 

Description  of  Factors 

DatDcl  =  Data  Declaration  (%)  *  10  10  10  0 

Display  =  Special  Display 

Requirements  *  31  not  given 

0  =  none 

1  =  simple  input/output 

2  =  user  friendly 

3  =  Interactive 

4  =  complex  requirements/ 

severe  Impact 

Languages  Used  as  %  of  Total  Equivalent  DSI 

HOL  3  Higher  Order  Language  (%}  77.4  86.4  95.6  1.0  100 

ASSMBLY  =  Assembly  Language  (%) 

=  (lOO-HOL)  22.6  13.6  4.4  99.0  0.0 

HOLang  »  Higher  Order  Language 

Used  (Name)  Jovial  ”  »  n  » 

Reusable  Code  From  Similar  Projects 

ADPLOC  s  #  of  DSLOC  adapted 
from  existing 

software  155400  72800  15900  24100  42600 

Design  =  %  Design  Modification 
required  (of  the 

original -design)  3.1  0.0  30.0  0.0  0.0 

Code  =  %  Code  Modification 

required  2.9  0.0  15.0  0.0  5.0 

Integr  »  %  Code  Integration 

required  29.9  50.0  50.0  0.0  5.0 
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Project  #24  (A,B,C,D)  24  A  B  C  D 

Description  of  Factors 

CPI  =  Conversion  Planning  Increment  not  given 

0  s  None 

1  -  Simple  conversion  schedule, 

acceptance  plan 

2  =  Detailed  conversion  schedule, 

test  and  acceptance  plans 

3  =  Add  basic  analysis  of  existing 

Inventory  of  code  and  data 

4  =  Add  detailed  Inventory,  basic 

documentation  of  existing 
system 

5  =  Add  detailed  Inventory,  detailed 

documentation  of  existing  system 

DOCUM  -  Documentation  Total 

(I  of  pages)  not  given 

SFtot  =  Software  Failure  History 

(Total  of  design  and  coding 
errors  documented  as  Software 
Trouble  Reports,  Software 
Problem  Reports 

(Total  I  of  STRs,  SPRs,  etc)  not  given 

IncrDevs  Incremental  Development 
(Can,  or  should  an 
Incremental  costing 
approach  be  used?) 


(Y/N?) 

yes 

yes 

yes 

yes 

yes 

D&Tcomp 

»  Development  and  Target 
Computers  (Same  or 
Different?) 

same 

same 

same 

same 

same 

CSCData 

=  CSC  Level  Data 
(Is  there  any?) 

* 

yes 

yes 

yes 

yes 

SCED  =  J 

(Y/N?) 

Schedule  Constraint 

1 

1 

1 

1 

1 

1.23  =  vlow 
1.08  =  low 
1.00  -  nom 
1.04  =  high 
1.10  =  vhlgh 
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Project  #24  (A,B,C,D)  24  A  B  C  D 

Description  of  Factors 

EFTpd  =  Effort  expended 
during  the 
preliminary  design 
phase 

(t  of  staff-months)  46.22  13.61  2.74  19.8  10.07 


EFTdd  =  Effort  expended  during 
the  detailed  design 
phase 

(I  of  staff-months) 

EFTcut  =  Effort  expended 

during  the  coding 
and  unit  testing 
phase  ( # 
staff-months ) 

EFTlt  3  Effort  expended  during 
the  integration  and 
testing  phase  (#  of 
staff-months ) 

EFTtot  =  Total  Effort 
Expended  In 
software 
Development  (# 
of  staff-months) 

Eunits  s  Units  In  which 
effort  was 
provided 

1  =  staff-months 

2  s  staff-hours 

Convfac  =  Conversion  factor 
from  staff-months 
to  staff-hours  (t) 

EPTcal  «  Normalized  total 
effort 

(#  staf f-months ) 


130.76  60.3  9.66  16.52  44.28 

95.66  48.85  10.13  13.69  22.99 

62.54  38.26  5.45  2.18  16.65 

335.18  161.02  27.98  52.19  93.99 

2  2  2  2  2 

152  152  152  152  152 

335.2  161.0  28.0  52.2  94.0 
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Project  124  (A,B,C,D)  24  A  B  C 

Description  of  Factors 

Months  =  Period  of  time  over 
which  EFTcal  value 
was  determined 

(i  of  months)  26  26  24  23 

Delta  T  =  Difference  between  the 
time  over  which  effort 
was  expended  and  the 
duration  of  the  software 
development.  Positive 
values  Indicate  that 
EFTcal  Includes  effort 
outside  the  COCOMO- 
deflned  software 
development  period. 

Negative  values  Indicate 
that  the  effort  data 
Is  Incomplete  EOSI 
s  Equivalent  number 
of  Deliverable  Source 
Instructions  for 

adapted  LOG.  (I)  0.0  0.0  -2.0  -2. 

TotEDSI  =  Total  Equivalent 
number  of 

Deliverable  Source 

Instructions  (»)  17207  10920  5009  0 

Mode  =  COCOMO  mode  of  software 
development,  as  defined 

in  table  below  E  E  SD  SD 

0  -  Organic 
SD  3  Semi-Detached 
E  -  Embedded 
FW  =  Firmware 

Concurnt  =  CSCIs  which  were 
concurrently 
developed  are 
assigned  the  same 

number  (!)  *  123 


12. 


26 


0  0.0 


1278 


SD 


120 


(page  17  of  18) 


Project  124  (A,B,C,D)  2i _ A  B  C  D 

Description  of  Factors 

COMMENTS  -  Unusual  aspects  of  programs, 
development  method,  or  other 
possible  cost-impact  Information. 

24  Missing  CDAs  taken  from  #19;  Effort  doesn't  Incl  B-5 
generation. 

24A  Orlg.  est.  94.4  KDSI;  Adapted  code  from  #23 

24B  Orlg.  est.  28.6  KDSI;  Adapted  code  from  #23 

24C  Orlg.  est.  47.3  KDSI;  Adapted  code  from  #23 

24D  Orlg.  est.  66.4  KDSI;  Adapted  code  from  #23 

Executive  =  Customer  of  the  contractor:  ESD/OC 


PQT-1  ®  Date  of  first 
Preliminary 
Qualification 

Test  (mm.yy)  *  11.83  10.83  12.83  12.83 


Incr-1  =  Total  DSI  accepted 
at  PQT-1 

Project  #24  * 

PQT-2  =  Date  of  second  Preliminary  not  given 
Qualification  Test 


Incr-2  =  Total  DSI  accepted  at  PQT-2  not  given 

PQT-3  =  Date  of  third  Preliminary  not  given 

Qualification  Test 


Incr-3  =  Total  DSI  accepted  at  PQT-3 
(Does  not  Include  Incr-1 
or  Incr-2)  not  given 


PQT-4  =  Date  of  fourth  Preliminary 

Qualification  Test,  if  any  not  given 

Incr-4  =  Total  DSI  accepted  at  PQT-4  not  given 

(does  not  Include  Incr-1, 

Incr-2,  or  Incr-3) 
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Project  #24  (A,B,C,D)  24  A  B  C  D 

Dsacriptiaii  ai  Eactflia 

Dffclty  =  Putnam's  Difficulty  Factor; 

This  Is  also  the  Initial 
slope  of  the  Rayleigh 
curve  that  Is  fit  to  the 
manloadlng  curve. 

(4*(total  effort)/ 


Development  Time) 2 

1. 

02  1. 

54  0.39 

* 

1.47 

Product  =  Productivity  =  Total 
(new  -»■  equivalent 
modified)  LOG/ 
Calibrated  effort 
(from  SDR  through 
FQT) 

(TEDSI/EFTcal) 

141.4 

160.4 

264.8 

103.5 

93.4 

AAF  «  Adaptation  Adjustment 
Factor  =  .4  x  Design  + 

.3  X  Code  +  .3  X  Integr 

11.1 

15.0 

31.5 

0.0 

3.0 

CAP  «  Conversion  Adjustment 
Factor  =  AAF  +  CPI 

11.1 

15.0 

31.5 

0.0 

3.0 

MewDSI  «  New  lines  of  code 

developed  =  Delivered 
LOC  -  modified  LOC 

30200 

14900 

2400 

5400 

7500 

Qeft  =  Qualify  factor  for  effort 

data  Code  #  5 

5 

5 

5 

5 

Qsize  =  Quality  factor  for 

TEDS I  data  Code  » 

3 

3 

3 

3 

3 

Date  »  Midpoint  year  of  the 
development  =  (date 
of  SDR  -f  date  of 

FQT)/2 

1983 

1983 

1983 

1983 

1983 

EAF  s  Effort  Adjustment 
factor  =  Product 
of  all  COCOMO  DEMs 
(») 

2.83 

5.09 

3.23 

2.09 

1.18 
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APPENDIX  D: 

Intermediate  COCOMO  Cost  Driver 
Ratings  and  Effort  Multipliers  for  Project  #24 

Cost  Driver  Rat log  Effort  Multiplier 


RELY 

H 

1.15 

DATA 

L 

0.94 

CPLX 

H 

1.15 

TIME 

VH 

1.30 

STOR 

EH 

1.56 

VI RT 

VL 

0.87 

TURN 

NOM 

1.00 

ACAP 

NOM 

1.00 

AEXP 

L 

1.13 

PCAP 

NOM 

1.00 

VEXP 

VL 

1.21 

LEXP 

VL 

1.14 

MPDP 

H 

0.91 

TOOL 

H 

0.91 

SCED 

NOM 

1.00 

EAF  =2.83 
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APPENDIX  E: 


PRICE'S  (MODE  2)  Input  Values 
Project  24  A,B,C,D 


ITEM  DESCRIPTORS 

Platform  1.8  Mgmt  Complexity  1.00  External  Integ  0.50 
COMPONENT  1  titled:  PROJECT  24  A 
DESCRIPTORS 

Internal  Integration  0.50  External  Integration  0.50 

Utilization  Fraction  0.75 

SCHEDULE 

Software  Spec  Review  982  Preliminary  Design  Review  0 

Critical  Design  Review  0  Test  Readiness  Review  0 

Functional  Config  Audit  0 


LANGUAGE  1  DESCRIPTORS 

Language  JOVIAL  Source  Code  75773 

Complexity  1  1.00  Complexity  2  1.00 


Non-executable  SLOC  0.10 

Productivity  Factor 

o 

o 

• 

Application  Categories 

Mix 

Mew  Design 

New  Code 

User  Defined  (APPL=0.00} 

0.00 

0.00 

0.00 

Data  S/R 

0.00 

0.00 

0.00 

Online  Comm 

0.10 

0.17 

0.17 

Realtime  C&C 

0.00 

0.00 

0.00 

Interactive 

0.35 

0.17 

0.17 

Mathematical 

0.55 

0.17 

0.17 

String  Manip 

0.00 

0.00 

0.00 

Opr  Systems  0.00 

LANGUAGE  2  DESCRIPTORS 

Language  ASSEMBLY  Source  Code 

Complexity  1  1.00  Complexity 

Non-executable  SLOC  0.10 
Productivity  Factor  4.00 

0.00 

11927 

2  1.00 

0.00 

Application  Categories 

Mix 

New  Design 

New  Code 

User  Defined  (APPL^O.OO) 

0.00 

0.00 

0.00 

Data  S/R 

0.00 

0.00 

0.00 

Online  Comm 

0.10 

0.17 

0.17 

Realtime  C&C 

0.00 

0.00 

0.00 

Interactive 

0.35 

0.17 

0.17 

Mathematical 

0.55 

0.17 

0.17 

String  Manip 

0.00 

0.00 

0.00 

Opr  Systems 

0.00 

0.00 

0.00 
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PRICE-S  (MODE  2)  Input  Values 
Project  24  A,B,C,D 

COMPONENT  2  titled:  PROJECT  24  B 

DESCRIPTORS 

Internal  Integration  0.50  External  Integration  0.50 

Utilization  Fraction  0.75 

SCHEDULE 

Software  Spec  Review  982  Preliminary  Design  Review  0 

Critical  Design  Review  0  Test  Readiness  Review  0 

Functional  Config  Audit  0 

LANGUAGE  1  DESCRIPTORS 

Language  JOVIAL  Source  Code  17495 

Complexity  1  1.00  Complexity  2  1.00 


Non-executable  SLOC  0.10 
Productivity  Factor  4.00 


Application  Categories 

Mix 

Mew  Design 

New  Code 

User  Defined  (APPL^O.OO) 

0.00 

0.00 

0.00 

Data  S/R 

0.05 

0.26 

0.26 

Online  Comm 

0.05 

0.26 

0.26 

Realtime  C&C 

0.00 

0.00 

0.00 

Interactive 

0.00 

0.00 

0.00 

Mathematical 

0.90 

0.26 

0.26 

String  Manip 

0.00 

0.00 

0.00 

Opr  Systems 

0.00 

0.00 

0.00 

LANGUAGE  2  DESCRIPTORS 

• 

Language  ASSEMBLY  Source  Code 

805 

Complexity  1  1.00  Complexity 

2  1.00 

Non-executable  SLOC  0.10 
Productivity  Factor  4.00 

Application  Categories 

Mix 

Mew  Design 

New  Code 

User  Defined  (APPL=0.00) 

0.00 

0.00 

0.00 

Data  S/R 

0.05 

0 . 26 

0.26 

Online  Comm 

0.05 

0.26 

0.26 

Realtime  C&C 

0.00 

0.00 

0.00 

Interactive 

0.00 

0.00 

0.00 

Mathematical 

0.90 

0.26 

0.26 

String  Manip 

0.00 

0.00 

0.00 

Opr  Systems 

0.00 

0.00 

0.00 
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PRICE-S  (MODE  2)  Input  Values 
Project  24  A,B,C,D 

COMPONENT  3  titled:  PROJECT  24  C 

DESCRIPTORS 

Internal  Integration  0.50  External  Integration  0.50 

Utilization  Fraction  0.75 

SCHEDULE 

Software  Spec  Review  982  Preliminary  Design  Review  0 

Critical  Design  Review  0  Test  Readiness  Review  0 

Functional  Config  Audit  0 

LANGUAGE  1  DESCRIPTORS 

Language  ASSEMBLY  Source  Code  29500 

Complexity  1  1.00  Complexity  2  1.00 

Non-executable  SLOC  0.10 
Productivity  Factor  4.00 


Application  Categories 

Mix 

New  Design 

New 

Code 

User  Defined  (APPL=0.00) 

0.00 

0.00 

0. 

.00 

Data  S/R 

0.10 

0.18 

0. 

,18 

Online  Comm 

0.00 

0.00 

0, 

.00 

Realtime  C&C 

0.00 

0.00 

0. 

.00 

Interactive 

0.00 

0.00 

0. 

.00 

Mathematical 

0.10 

0.18 

0. 

.18 

String  Manip 

0.80 

0.18 

0, 

.18 

Opr  Systems 

0.00 

0.00 

0. 

.00 
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PRICE-S  (MODE  2)  Input  Values 
Project  24  A,B,C,D 

COMPONENT  4  titled:  PROJECT  24  D 

DESCRIPTORS 

Internal  Integration  0.50  External  Integration  0.50 

Utilization  Fraction  0.50 

SCHEDULE 

Software  Spec  Review  982  Preliminary  Design  Review  0 

Critical  Design  Review  0  Test  Readiness  Review  0 

Functional  Config  Audit  0 

LANGUAGE  1  DESCRIPTORS 

Language  JOVIAL  Source  Code  50100 

Complexity  1  1.00  Complexity  2  1.00 

Non-executable  SLOC  0.00 
Productivity  Factor  4.00 


Application  Categories 

Mix 

New  Design 

New 

Code 

User  Defined  (APPL^O.OO) 

0.00 

0.00 

0. 

.00 

Data  S/R 

0.04 

0.19 

0. 

.19 

Online  Conua 

0.11 

0.19 

0, 

.19 

Realtime  C&C 

0.00 

0.00 

0. 

.00 

Interactive 

0.12 

0.19 

0. 

.19 

Mathematical 

0.31 

0.19 

0, 

,19 

String  Manip 

0.42 

0.19 

0. 

,19 

Opr  Systems 

0.00 

0.00 

0. 

.00 
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APPENDIX  F 


PRICB-S  (MODS  2)  BstlMtion  SUMMiy 
Project  24  A,B,C,D 


COSTS  IN  PERSON  MONTHS 


Design 

Prog 

Data 

S/PM 

1  Q/A 

Connf ig 

Total 

Sys  Concept 

0. 

0. 

0. 

0. 

0. 

0. 

0. 

Sys/SV  Reqt 

0. 

0. 

0. 

0. 

0. 

0. 

0. 

SN  RequiresMnt 

134. 

0. 

28. 

49. 

26. 

25. 

262. 

Prelim  Design 

97. 

16. 

20. 

33. 

18. 

18. 

203. 

Detail  Design 

130. 

60. 

28. 

43. 

25. 

27. 

313. 

Code/Test 

93. 

67. 

22. 

33. 

21. 

23. 

259. 

CSCI  Test 

145. 

146. 

52. 

68. 

48. 

55. 

514. 

System  Test 

0. 

0. 

0. 

0. 

0. 

0. 

0. 

Oper  TAB 

0. 

0. 

0. 

0. 

0. 

0. 

0. 

Sub-Total 

599. 

289. 

150. 

226. 

138. 

148. 

1550. 

Purchased  Cost 

- 

- 

- 

- 

- 

mm 

0. 

TOTAL 

- 

- 

- 

- 

- 

- 

1550. 

SCHEDULE 

INFORMATION 

Concept  Start 

SEP 

81 

TRR 

OCT  83 

( 

4.1) 

SSR 

NOV 

81  (  3. 

5) 

FCA 

AUO  84 

(10.0) 

SDR 

FEB 

82  (  2. 

3) 

PCA 

NOV  84 

( 

3.1) 

SSR 

SEP 

82  (  7. 

2) 

FOR 

FEB  85 

( 

3.1) 

PDR 

JAM 

83  (  4. 

0) 

0TB 

OCT  85 

( 

7.7) 

COR 

JUN 

83  (  5.1) 

NOTE:  The  time  frame  considered  for  comparison 

is 

highlighted 

in  bold  print.’ 


SUPPLEMENTAL  INFORMATION 

Source  Lines  of  Code  18$€00 

Source  Lines  of  Code/Person  Month  144.0 
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APPENDIX  G: 

SOFTCOST-R  INPUT  VALUES 

Project  124 


SIZING  FACTORS 


Lines  of  executable  source  code: 

MAX 

AVG 

MIN 

New: 

34.7 

30.2 

25.6 

In  existing  modules  requiring 
modification: 

5.2 

4.5 

3.8 

Deleted  from  existing  modules: 

0 

0 

0 

Added  to  existing  modules: 

0 

0 

0 

Changed  in  other  ways  in  existing 
modules : 

0 

0 

0 

Deleted  as  entire  modules 

0 

0 

0 

Retested  but  remained  unchanged 

0 

0 

0 

Percentage  of  source  code  developed  that  will  be 
delivered  =  High 


MANAGEMENT  FACTORS 

Phase  of  the  life  cycle  software  work  will  begin:  System 
Requirements  Phase 

Percentage  of  total  software  requirements^ 

Well  established,  stable,  and  will  not  change  before 
delivery:  85 

Will  change  slightly  before  delivery  (under  baseline 
control ) :  15 

Will  change  more  drastically  before  delivery  (under 
baseline  control):  0 

Complexity  of  software  requirements:  High 
Expected  user  involvement  in  requirements  definition:  Low 
Customer  experience  in  the  application  area:  Low 
Customer/ implementor  organizational  interface 
complexity:  Medium 

Level  of  interfaces  with  other  projects  or 
organizations:  High 

Efficiency  of  implementing  organization:  Medium 
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SOFTCOST-R  INPUT  VALUES 


Project  #24 
STAFFING  FACTORS 


Overall  personnel  qualifications  of  the  team:  Low 
Percentage  of  programmers  doing  design  and  working 
development:  High 

Team's  experience  with  projects  of  similar  size  and 
complexity:  low 

Average  staff  experience  (in  years):  3 


Staff  experience  with: 

the  operational  computer (s):  Low 

the  programming  languages:  Low 

top-down  methodology:  Medium 

team  concepts:  Medium 

structured  programming:  Low 

Type  of  technical  reviews  held:  High 


COMPLEXITY  FACTORS 


Number  of  different  I/O  items  generated  per  1000  lines: 
Overall  complexity  of  the  data  base  architecture:  Low 
Complexity  of  the  logical  design:  Medium 
Percentage  of  the: 

program  will  be  in  assembly  language:  22 


program  will  be  storage  optimized:  90 
program  will  be  timing  optimized:  78 
total  task  will  be  easy:  84 
total  task  will  be  hard:  16 


ENVIRONMENTAL  FACTORS 

Classified  security  environment  for  computer:  Y 
Amount  of  hardware  under  concurrent  development:  Medium 
Percent  of  work  done  at  primary  development  site:  High 
Development  computer  accessibility:  High 
Development  computer  availability:  High 
Software  development  tools/environment  reliability:  High 
Maturity  of  system  and  support  software:  Medium 
Overall  adverse  constraints  on  program  design:  Medium 
Percent  of  program  which  is  real-time  and  multi-tasking: 
Software  will  be  adapted  to  multiple  environments:  N 
Adaptation  required  to  change  from  development  to 
operational  environment:  Medium 


Low 


Low 
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APPENDIX  H: 


SOFTCOST-R  RESOURCES  ESTIMATE 


PROJECT  #24 
Calculated; 


Effort  (person-months):  126.0 

Duration  (months):  21.1 

Average  Staff  (persons):  6.0 

Productivity  (SLEC/person-month) :  249.2 

Adjusted  source  lines  of  executable  code  (KSLEC):  31.4 
Confidence:  10.9% 
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APPENDIX  X 


SPOR/20  INPUT  VALUES 


Project  124 

ESTIMATE  AND  FINANCIAL  INPUTS 
Estlaate  Type:  New  Prograa 

Estlaate  Scope:  Coaplete  stand-alone  prograa 
EstiMate  Goals:  find  the  noraal  average  of  staff  size, 
schedules,  and  quality 
Maxlmia  Staff  Size:  Noraal 
Minima  Staff  Size:  Noraal 
Output  Metric:  Work  Months  (Default) 

Staff  Availability:  100% 

Exea^t  Technical  Staff:  100% 

Average  Work  Week:  40  hours 
Average  Work  Year:  220  days 
Average  Monthly  Salary:  5000  (default) 

Other  Project  Costs:  0 

PROJECT  CLASS:  External  prograa  developed  under  Military 
Specifications 

PROJECT  TYPE:  Eabedded  or  Realtlae  prograa 
ENVIRONMENTAL  INPUTS 

Project  Novelty:  Functional  repeat,  but  soae  new  features 
Office  Facilities:  Doubled  offices  and  good  facilities 
Prograa  Requlreaents:  Fairly  clear  user  regulreaents 
Prograa  Design:  New  designs  and  partial  autoaated  graphics/ 
text  design  support 

User  Docuaentatlon:  Prograaaers  or  users  with  fully 
autoaated  graphics/text  support 
Response  tiae:  One  to  five  second  response  tlae  In  the 
nora 

Staff  Experience:  Majority  of  new  hires  or  novices,  with 
few  experts 

Source  Code  Reusability:  Extensive  use  of  reusable  code 
075%) 
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SPQR/20  INPUT  VALUES 


Project  #24 

REUSABLE  CODE  LANGUAGE 

Source  Language:  Mixed  languages 
Language  Level:  3 

REUSABLE  CODE  SIZE  (KLOC) :  155.4 

REUSABLE  FUNCTION  POINTS:  1,456 

LINES  PER  FUNCTION  POINT:  106.73 

NEW  PROJECT  COMPLEXITY 

Logical  Complexity:  Algorithms  and  calculations  of  average 
complexity 

Code  Complexity:  Fair  structure,  but  some  complex  modules 
and  paths 

Data  Complexity:  Simple  data  with  few  variables  and  low 
complexity 

NEW  CODE  SOURCE  LANGUAGE 

Source  Language:  Mixed  languages 
Language  Level:  3 

MEW  CODE  SIZE  (KLOC):  30.2 
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APPENDIX  J 


SPQR/20  SUMMARY  ESTIMATE 


PROJECT  S24 

MODE  1:  Normal  Average  SECURITY:  NONE 

START  DATE:  SEPTEMBER  1982  END  DATE:  AUGUST  1984 

PROJECT  DEVELOPMENT  ESTIMATE 


ACTIVITY 


SCHEDULE  EFFORT 

(MONTHS)  (MONTHS) 


Planning 

Requirements 

Design 

Coding 

Integration/Test 

Documentation 

Management 


1.33 

1.33 

2.08 

5.61 

8.70 

26.83 

10.20 

33.76 

8.22 

28.18 

11.05 

22.44 

23.17 

20.40 

Development  30.54  138.55 

Overlapped  23.17 

Unpaid  Overtime  0.00 
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APPENDIX  K: 


System-3  Input  Values 


Project  #24 


DEVELOPER  TECHNOLOGY 

Minimum 

Nominal 

Maximum 

APPLicatlon  Complexity 

2.0 

2.6 

2.0 

Analyst  CAPabillty 

3.5 

5.5 

7.5 

Application  Experience 

0.3 

0.3 

1.0 

MODern  Practices,  use  of 

7.5 

7.5 

7.5 

Programmer  CAPabillty 

3.5 

5.5 

7.5 

TOOL  support,  automated 

7.5 

7.5 

7.5 

TURNaround,  logon-hardcopy 

2.0 

2.0 

2.0 

ENVIRONMENTAL  -  COMPUTER 

DISP  req'mt,  special 

0.0 

3.2 

6.8 

MEMory  Constraint 

4.0 

4.0 

4.0 

TIMe  Constraint 

0.0 

0.0 

0.0 

Real  TIMe 

2.5 

5.0 

5.0 

ENVIRONMENTAL  -  PRODUCT 

SPECiflcatlon  Level 

4.0 

6.0 

6.0 

QUALity  Assurance  Level 

4.0 

6.0 

6.0 

TEST  Level 

4.0 

6.0 

6.0 

Requirements  CHanGe  vol 

1.3 

1.3 

4.0 

ReHOSTing  develop->target 

0.0 

0.0 

0.0 

LANGuage  type  rating 

1.0 

1.0 

1.0 

Language  Experience 

0.5 

1.5 

2.0 

SYSTem  complexity-virtual 

2.0 

2.0 

2.0 

System  EXPer ience-virtual 

0.5 

1.0 

1.0 

Virtual  Mach.  VoLatillty 

0.0 

2.5 

2.5 

ENVIRONMENTAL  -  SUPPORT 

MULTiple  site  development 

0.0 

0.0 

0.0 

Resource  DEDication 

7.0 

10.0 

10.0 

Resource/support  Location 

0.0 

0.0 

0.0 

SIZE  &  COMPLEXITY  SUMMARY 

New  Lines  of  Code 

25670 

30200 

34730 

Existing  Lines  of  Code  132090 

155400 

178710 

Lines  to  be  Deleted 

0 

0 

0 

Lines  to  be  Modified 

3830 

4507 

5183 

Complexity 

11.0 

11.0 

11.0 

DEVELOPMENT  CONSTRAINTS 

Staffing  Rate  (Persons/Yr) 
Maximum  Staff  (Persons) 
Maximum  Effort  (Person  Mos) 

0.0 

0.0 

0.0 

o 

• 

o 

0.0 
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System- 3  Input  Values 


Project  924 

Minimum  Nominal 


REUSE  -  REBUILD  IMPACT 
%  Design  Effort  Needed  16.0 

%  Implement  Eff.  Needed  16.0 

%  Testing  Effor*-  Needed  16.0 

FINANCIAL  FACTORS 

Average  Staff  Pay  Rate  11000.0 
Target  Schedule  0.0 

%  Requirements  Effort  8.0 

Req*s  Eff.  Complete  %  C/A  0.0 

Req's  Schedule  Constraint  0.0 

\  Integration  Effort  29.0 

Avg.  Annual  Inflation  0.0 


Maximum 
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APPENDIX  L: 


System-3  Summary  Report 

Project  #24 

(Minimum  Time)  Estimate 
FULL  SCALE  DEVELOPMENT 


Development  Time 

20.74 

Months 

Development  Effort 

272.69 

Person  Months 

Project  Staff,  Peak 

19.93 

Persons 

Actual  Staffing  Rate 

19.01 

Persons/Year 

Productivity 

127.28 

Lines/Staff /Month 

REQUIREMENTS  AND  INTEGRATION 

Requirements  Time 

8.82 

Months 

Requirements  Effort 

53.32 

Person  Months 

Total  Requirements  Cost 

584.65 

K-Dollars 

Integration  Time 

3.95 

Months 

Integration  Effort 

79.08 

Person  Months 

Complexity 

11.00 

Basic  Technology  Rating 

5730.08 

Effective  Technology  Rating 

2279.33 

Effective  Task  Size  29S96 

Total  Task  Size  185600 
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APPENDIX  M: 


COCOMO  Software  Development  Effort  Multipliers  (5; 118) 

Ratings 


Very 

Low  Nominal  High 

Very 

Extra 

Low 

High 

High 

Product  Attributes  ^  .. 

RELY  • 7  5 

.88 

1.00 

1.15 

1.40 

DATA 

.94 

1.00 

1.08 

1.16 

1.65 

CPLX  .70 

.85 

1.00 

1.15 

1.30 

Computer  Attributes 

TIME 

1.00 

1.11 

1.30 

1.66 

STOR 

1.00 

1.06 

1.21 

1 . 56 

VIRT 

.87 

1.00 

1.15 

1.30 

TURN 

.87 

1.00 

1.07 

1.15 

Personnel  Attributes 

ACAP  1.46 

1.19 

1.00 

.86 

.71 

AEXP  1.29 

1.13 

1.00 

.91 

.  82 

PCAP  1.42 

1.17 

1.00 

.86 

.  70 

VEXP  1.21 

LEXP  1.14 

Project  Attributes 

MODP  1.24 

1.10 

1.07 

1.10 

1.00 

i.bo 

1.00 

.90 

.95 

.91 

.82 

TOOL  1.24 

1.10 

1.00 

.91 

.  83 

SCED  1.23 

1.08 

1.00 

1.04 

1.10 
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